Kerja Sama Tim Tanpa Kebingungan: Memahami Strategi Percabangan di Git

Perkenalan

Git telah menjadi standar industri de facto untuk kontrol versi dalam pembuatan perangkat lunak. Untuk mempelajari tentang apa itu git dan bagaimana memulainya, baca dulu artikel saya tentang git. Sudahkah Anda membacanya? Bagus, ayo kita lanjutkan! Suka atau tidak suka, instrumen yang diciptakan Linus Towalds tidak akan pensiun. Oleh karena itu, masuk akal untuk membicarakan cara kerja tim terdistribusi di git dan strategi percabangan apa yang harus dipilih untuk ini. Dan ini sama sekali bukan pertanyaan kosong. Seringkali, dalam situasi di mana tim pengembang baru yang belum berkolaborasi satu sama lain dibentuk, strategi percabangan adalah salah satu hal pertama yang perlu diputuskan. Dan akan ada orang yang mulutnya berbusa untuk membuktikan bahwa satu strategi lebih baik dari yang lain. Oleh karena itu, saya ingin menyampaikan kepada Anda informasi tentang apa itu umumnya.

Apakah strategi percabangan diperlukan?

Tapi mereka dibutuhkan, dan masih dibutuhkan. Karena jika ada yang tidak disepakati dalam tim, ternyata semua orang akan menuruti keinginannya:

• bekerja di cabang yang dia inginkan;
• bergabung ke cabang lain yang dia inginkan;
• hapus beberapa cabang;
• buat yang baru;
• dan seterusnya—setiap anggota tim berada dalam arus yang tidak terkendali.

Oleh karena itu, di bawah ini ada tiga strategi. Pergi!

Strategi Aliran GitHub

Strategi percabangan, betapapun anehnya, lebih disukai di GitHub :) Terlampir di dalamnya adalah serangkaian aturan yang perlu diikuti:

1. Kode di cabang master harus tidak terputus dan siap untuk diterapkan kapan saja (yaitu, Anda tidak dapat meletakkan kode di sana yang akan menghalangi Anda membangun proyek dan menerapkannya di server).
2. Saat Anda berencana untuk mengerjakan fungsionalitas baru, Anda perlu membuat cabang baru (cabang fitur) berdasarkan cabang master dan memberinya nama yang bermakna. Komit kode Anda secara lokal dan dorong perubahan Anda secara teratur ke cabang yang sama di repositori jarak jauh.
3. Buka Pull-Request (Anda dapat membaca apa yang dimaksud dengan pull-request di sini ) ketika ada perasaan yang jelas bahwa pekerjaan sudah siap dan dapat digabungkan ke dalam cabang master (atau jika Anda tidak yakin, tetapi ingin mendapatkan umpan balik tentang pekerjaan yang dilakukan).
4. Setelah fitur baru dalam permintaan tarik disetujui, fitur tersebut dapat digabungkan ke dalam cabang master.
5. Ketika perubahan digabungkan ke dalam cabang master, perubahan tersebut harus segera disebarkan ke server.

Menurut GitHub Flow, ternyata sebelum Anda mulai mengerjakan sesuatu yang baru, baik itu perbaikan atau fitur baru, Anda perlu membuat cabang baru berdasarkan master dan memberinya nama yang sesuai. Selanjutnya, pekerjaan implementasi dimulai. Anda harus terus-menerus mendorong komitmen ke server jauh dengan nama yang sama. Ketika Anda memahami bahwa semuanya sudah siap, Anda perlu membuat permintaan tarik di cabang master. Maka setidaknya satu, atau lebih baik lagi, dua orang harus melihat kode ini dan klik Setujui. Biasanya, pimpinan tim proyek dan orang lain harus melihatnya, lalu Anda dapat menyelesaikan permintaan penarikan. GitHub Flow juga dikenal mendorong Pengiriman Berkelanjutan (CD) pada sebuah proyek. Karena ketika perubahan dilakukan pada cabang master, harus segera di-deploy ke server.

Strategi GitFlow

Strategi sebelumnya (GitHub Flow) pada dasarnya tidak terlalu rumit. Ada dua jenis cabang: cabang master dan fitur. Tapi GitFlow lebih serius. Setidaknya dari gambar di atas Anda bisa memahaminya) Lalu, bagaimana cara kerja strategi ini? Secara umum GitFlow terdiri dari dua cabang permanen dan beberapa jenis cabang sementara (Dalam konteks GitHub Flow, cabang master bersifat permanen dan yang lainnya bersifat sementara). Cabang permanen:

• master: tidak seorang pun boleh menyentuh cabang ini atau mendorong apa pun di sana. Dalam strategi ini, master menampilkan versi stabil terbaru yang digunakan dalam produksi (yaitu, di server sebenarnya);
• pembangunan adalah cabang dari pembangunan. Ini berpotensi menjadi tidak stabil.

Pembangunan dilakukan dengan menggunakan tiga cabang sementara tambahan :

1. Cabang fitur - untuk mengembangkan fungsionalitas baru.
2. Cabang rilis - untuk mempersiapkan rilis versi baru proyek.
3. Cabang perbaikan terbaru adalah solusi cepat terhadap kerusakan yang telah ditemukan oleh pengguna sebenarnya di server nyata.

Cabang fitur

Cabang fitur dibuat oleh pengembang untuk fungsionalitas baru. Mereka harus selalu dibuat berdasarkan cabang pengembangan. Setelah menyelesaikan pengerjaan fungsionalitas baru, Anda perlu membuat permintaan tarik di cabang pengembangan. Jelas bahwa dalam tim besar mungkin terdapat lebih dari satu cabang fitur dalam satu waktu. Sekali lagi perhatikan gambar di awal deskripsi strategi GitFlow.

Lepaskan cabang

Ketika jumlah fitur baru yang diperlukan telah disiapkan di cabang pengembangan, Anda dapat bersiap untuk merilis versi produk yang baru. Cabang rilis akan membantu kami dalam hal ini. yang dibuat berdasarkan cabang pengembangan. Saat bekerja dengan cabang rilis, Anda perlu menemukan dan memperbaiki semua cacat. Setiap perubahan baru yang diperlukan untuk menstabilkan cabang rilis juga harus digabungkan kembali ke dalam pengembangan. Hal ini dilakukan dalam rangka pemantapan dan pengembangan cabang. Ketika penguji mengatakan bahwa cabang tersebut cukup stabil untuk rilis baru, cabang tersebut digabungkan ke dalam cabang master. Selanjutnya, sebuah tag dibuat pada komit ini (tag: Anda dapat membacanya lebih lanjut di sini ), yang diberi nomor versi. Sebagai contoh, Anda bisa melihat gambar di awal strategi. Jadi, Tag 1.0 hanyalah label yang menunjukkan versi 1.0 dari proyek tersebut. Dan yang terakhir adalah perbaikan terbaru cabang.

Cabang perbaikan terbaru

Cabang perbaikan terbaru juga dimaksudkan untuk rilis versi baru di master. Satu-satunya perbedaan adalah rilis ini tidak direncanakan. Ada situasi ketika cacat mencapai rilis dan sudah ditemukan dalam produksi. Misalnya, iOS: segera setelah mereka merilis versi baru, Anda segera mendapatkan banyak pembaruan dengan perbaikan untuk cacat yang ditemukan setelah rilis. Dalam hal ini, cacat ini perlu segera diperbaiki dan dirilis versi baru. Dalam gambar kami ini sesuai dengan versi 1.0.1. Idenya adalah bahwa pengerjaan fungsionalitas baru mungkin tidak berhenti pada saat Anda perlu memperbaiki kerusakan pada server sebenarnya (seperti yang kami katakan, “dalam produksi”: sekali lagi, salinan dari kata produksi dalam bahasa Inggris). Cabang perbaikan terbaru harus dibuat dari cabang master, karena cabang ini mewakili keadaan yang berfungsi dalam produksi. Segera setelah solusi terhadap cacat tersebut siap, solusi tersebut digabungkan ke dalam master, dan label baru dibuat. Sama seperti menyiapkan cabang rilis, cabang perbaikan terbaru harus menggabungkan solusinya ke dalam cabang pengembangan.

Strategi Alur Kerja Forking

Sebagai bagian dari strategi Forking Workflow, pengembangan dilakukan sedemikian rupa sehingga terdapat dua repositori:

1. Repositori asli tempat semua perubahan akan digabungkan.
2. Repositori fork (ini adalah salinan dari repositori asli yang dimiliki oleh pengembang lain yang ingin melakukan perubahan pada aslinya).

Kedengarannya agak aneh sejauh ini, bukan? Bagi mereka yang pernah mengenal pengembangan sumber terbuka, pendekatan ini sudah tidak asing lagi. Strategi ini memberikan keuntungan sebagai berikut: pengembangan dapat dilakukan dalam repositori fork tanpa memberikan hak untuk pengembangan bersama pada repositori aslinya. Tentu saja, pemilik repositori asli berhak menolak usulan perubahan. Atau setuju dan bunuh mereka. Hal ini memudahkan pemilik repositori asli dan pengembang yang ingin berpartisipasi dalam pembuatan suatu produk. Misalnya, Anda dapat mengusulkan perubahan pada kernel Linux . Jika Linus menganggapnya masuk akal, perubahan akan ditambahkan (!!!).

Contoh Alur Kerja Forking

Aliran Forking digunakan di GitHub ketika ada beberapa perpustakaan yang ingin Anda gunakan. Ada cacat yang menghalanginya untuk digunakan sepenuhnya. Katakanlah Anda sudah cukup mendalami masalahnya dan mengetahui solusinya. Dengan menggunakan strategi Alur Kerja Forking, Anda dapat mengatasi masalah ini tanpa memberikan hak untuk bekerja di repositori perpustakaan asli. Untuk memulai, Anda perlu memilih repositori, misalnya, inti Spring Framework Temukan tombol Fork di sudut kanan atas dan klik: Ini akan memakan waktu, setelah itu salinan repositori asli ini akan muncul di Anda akun pribadi, yang akan menunjukkan bahwa itu adalah fork: Kemudian Anda dapat bekerja dengan repositori ini seperti biasa, menambahkan perubahan ke cabang master dan ketika semuanya sudah siap, buat Permintaan Tarik ke repositori asli. Untuk melakukan ini, klik tombol Permintaan Tarik Baru :

Strategi mana yang harus dipilih

Git adalah alat yang fleksibel dan kuat yang memungkinkan Anda bekerja menggunakan berbagai proses dan strategi. Namun semakin besar pilihannya, semakin sulit menentukan strategi mana yang harus dipilih saat ini. Jelasnya, tidak ada jawaban yang bisa universal. Semua tergantung pada situasinya. Namun, ada beberapa rekomendasi yang dapat membantu dalam hal ini:

1. Lebih baik memilih strategi yang paling sederhana terlebih dahulu. Beralih ke strategi yang lebih kompleks hanya jika diperlukan.
2. Pertimbangkan strategi yang memiliki jenis cabang pengembang sesedikit mungkin.
3. Lihatlah pro dan kontra dari berbagai strategi dan, sesuai dengan proyek, pilihlah yang tepat.

Itu saja yang ingin saya sampaikan kepada Anda tentang strategi percabangan di git. Terima kasih atas perhatiannya :) Berlangganan ke akun GitHub saya , saya sering memposting karya saya di sana dalam berbagai teknologi dan alat yang saya gunakan dalam pekerjaan saya

tautan yang bermanfaat

• Aliran GitHub: cara terbaik menggunakan Git dan GitHub
• Tarik permintaan di GitHub atau Bagaimana cara membuat perubahan pada proyek orang lain
• GitHub: Tentang Permintaan Tarik
• Integrasi Berkelanjutan, Pengiriman, dan Penerapan Dibedakan
• Dasar-Dasar Git: Bekerja dengan Tag
• Habr: Model percabangan yang sukses untuk Git