Kerja tim tanpa kebingungan: memahami strategi percabangan di Git

Perkenalan

Git telah menjadi standar industri de facto untuk sistem kontrol versi dalam pengembangan perangkat lunak. Anda harus terlebih dahulu membaca artikel saya tentang apa itu Git dan bagaimana memulainya. Sudahkah Anda membacanya? Luar biasa, ayo pergi! Suka tidak suka, alat yang dibuat oleh Linus Tovalds ini tidak akan pensiun. Jadi, masuk akal untuk berbicara tentang bagaimana tim terdistribusi bekerja dengan Git dan strategi percabangan apa yang harus mereka pilih untuk ini. Ini bukan pertanyaan yang tidak penting. Saat menyusun tim pengembangan baru yang belum pernah bekerja sama sebelumnya, strategi percabangan seringkali menjadi salah satu hal pertama yang harus diputuskan. Dan beberapa orang akan berbusa di mulut untuk membuktikan bahwa satu strategi lebih baik dari yang lain. Jadi, saya ingin menyampaikan kepada Anda beberapa informasi umum tentang mereka.

Apakah strategi percabangan diperlukan?

Mereka memang diperlukan. Sangat penting. Karena jika tim tidak menyepakati sesuatu, maka setiap anggota tim akan melakukan apa yang diinginkannya:

• bekerja di cabang manapun
• menggabungkan ke cabang-cabang lain yang sewenang-wenang
• menghapus beberapa cabang
• menciptakan yang baru
• sehingga setiap anggota tim akan bertindak dalam aliran yang tidak terkelola.

Itu sebabnya kami memiliki tiga strategi untuk dipertimbangkan di bawah ini. Ayo pergi!

Aliran GitHub

Anehnya, strategi percabangan ini lebih disukai di GitHub :) Muncul dengan seperangkat aturan :

1. Kode di cabang master tidak boleh rusak. Itu harus siap untuk digunakan kapan saja. Artinya, Anda tidak boleh meletakkan kode di sana yang akan mencegah Anda membangun proyek dan menyebarkannya ke server.
2. Saat Anda berencana untuk mengerjakan fungsionalitas baru, Anda perlu membuat cabang fitur baru 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 tentang pull request di sini ) saat menurut Anda pekerjaan sudah siap dan dapat digabungkan ke dalam cabang master (atau jika Anda tidak yakin, tetapi ingin mendapatkan umpan balik tentang pekerjaan yang telah diselesaikan).
4. Setelah fitur baru dalam pull request disetujui, fitur tersebut dapat digabungkan ke dalam cabang master.
5. Saat perubahan digabungkan ke dalam cabang master, perubahan tersebut harus segera diterapkan ke server.

Menurut Aliran GitHub, 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, pengerjaan implementasi dimulai. Anda harus selalu mengirimkan komit ke server jarak jauh dengan nama yang sama. Saat Anda menyimpulkan bahwa semuanya sudah siap, Anda perlu membuat permintaan tarik ke cabang master. Maka setidaknya satu, atau lebih baik lagi, dua orang harus melihat kode ini sebelum mengklik "Setuju". Biasanya, pimpinan tim proyek dan orang kedua pasti harus melihatnya. Kemudian Anda dapat menyelesaikan permintaan penarikan. Aliran GitHub juga dikenal untuk mendorong pengiriman berkelanjutan (CD) dalam proyek. Ini karena ketika perubahan masuk ke cabang master, mereka harus segera diterapkan ke server.

GitFlow

Strategi sebelumnya (Aliran GitHub) pada intinya tidak terlalu rumit. Ada dua jenis cabang: cabang master dan fitur. Tapi GitFlow lebih serius. Setidaknya, gambar di atas harus menjelaskannya :) Jadi bagaimana cara kerja strategi ini? Secara umum, GitFlow terdiri dari dua cabang persisten dan beberapa jenis cabang sementara. Dalam konteks Aliran GitHub, cabang master bersifat persisten dan yang lainnya bersifat sementara. Cabang-cabang yang gigih

• master: Tidak seorang pun boleh menyentuh atau mendorong apa pun ke cabang ini. Dalam strategi ini, master mewakili versi stabil terbaru, yang digunakan dalam produksi (yaitu, di server sebenarnya)
• pengembangan: Cabang pengembangan. Itu bisa menjadi tidak stabil.

Pengembangan terjadi menggunakan tiga cabang tambahan sementara :

1. Cabang fitur — untuk mengembangkan fungsionalitas baru.
2. Cabang rilis — untuk mempersiapkan rilis versi baru proyek.
3. Cabang hotfix — untuk memperbaiki bug yang ditemukan oleh pengguna nyata di server nyata dengan cepat.

Cabang fitur

Cabang fitur dibuat oleh pengembang untuk fungsionalitas baru. Mereka harus selalu dibuat berdasarkan cabang pengembangan. Setelah menyelesaikan pekerjaan pada fungsionalitas baru, Anda perlu membuat permintaan tarik ke cabang pengembangan. Jelas, tim besar dapat memiliki lebih dari satu cabang fitur sekaligus. Perhatikan lagi gambar di awal deskripsi strategi GitFlow.

Lepaskan cabang

Saat kumpulan fitur baru yang diperlukan sudah siap di cabang pengembangan, Anda dapat mempersiapkan rilis versi baru produk. Cabang rilis, yang dibuat berdasarkan cabang pengembangan, akan membantu kita dalam hal ini. Saat bekerja dengan cabang rilis, Anda perlu menemukan dan memperbaiki semua bug. Setiap perubahan baru yang diperlukan untuk menstabilkan cabang rilis juga harus digabungkan kembali ke dalam cabang pengembangan. Ini dilakukan untuk menstabilkan cabang pembangunan juga. Saat penguji mengatakan bahwa cabang tersebut cukup stabil untuk rilis baru, cabang tersebut digabungkan ke dalam cabang master. Kemudian tag, yang diberi nomor versi, dibuat untuk komit ini. Untuk melihat contohnya, lihat gambar di awal strategi. Di sana Anda akan melihat Tag 1.0— ini hanyalah tag yang menunjukkan versi 1.0 proyek. Dan akhirnya, kami memiliki cabang hotfix.

Cabang hotfix

Cabang hotfix juga dimaksudkan untuk merilis versi baru ke cabang master. Satu-satunya perbedaan adalah rilis tersebut tidak direncanakan. Ada situasi ketika bug masuk ke versi rilis dan ditemukan di lingkungan produksi. Ambil iOS: segera setelah versi baru dirilis, Anda segera mendapatkan banyak pembaruan dengan perbaikan bug yang ditemukan setelah rilis. Oleh karena itu, kami perlu memperbaiki bug dengan cepat dan merilis versi baru. Dalam gambar kami, ini sesuai dengan versi 1.0.1. Idenya adalah bahwa bekerja pada fungsionalitas baru tidak harus berhenti ketika diperlukan untuk memperbaiki bug di server nyata (atau seperti yang kami katakan, "in prod" atau "in production"). Cabang hotfix harus dibuat dari cabang master, karena mewakili apa yang sedang berjalan dalam produksi. Segera setelah perbaikan bug siap, itu digabungkan menjadi master, dan tag baru dibuat. Sama seperti menyiapkan cabang rilis, cabang hotfix juga harus menggabungkan perbaikannya kembali ke cabang pengembangan.

Forking alur kerja

Dalam alur kerja forking, pengembangan melibatkan dua repositori:

1. Repositori asli, tempat semua perubahan akan digabungkan.
2. Repositori garpu. Ini adalah salinan dari repositori asli, yang dimiliki oleh pengembang lain yang ingin melakukan perubahan pada aslinya.

Kedengarannya agak aneh sejauh ini, bukan? Siapa pun yang pernah mengalami pengembangan sumber terbuka sudah terbiasa dengan pendekatan ini. Strategi ini memberikan keuntungan sebagai berikut: pengembangan dapat terjadi di repositori fork tanpa memberikan izin untuk pengembangan bersama di cabang aslinya. Secara alami, pemilik repositori asli memiliki hak untuk menolak perubahan yang diusulkan. Atau untuk menerima dan menggabungkannya. Ini nyaman bagi pemilik repositori asli dan pengembang yang ingin membantu membuat produk. Misalnya, Anda dapat menyarankan perubahan pada kernel Linux . Jika Linus memutuskan itu masuk akal, perubahan akan ditambahkan (!!!).

Contoh alur kerja forking

Alur kerja forking diterapkan di GitHub saat ada pustaka yang ingin Anda gunakan. Ini memiliki bug yang mencegah Anda menggunakannya sepenuhnya. Misalkan Anda menyelami masalah tersebut cukup dalam dan mengetahui solusinya. Menggunakan alur kerja forking, Anda dapat memperbaiki masalah tanpa hak untuk bekerja di repositori asli perpustakaan. Untuk memulai, Anda perlu memilih beberapa repositori, misalnya Spring Framework . Temukan dan klik tombol "Fork" di sudut kanan atas: Ini akan memakan waktu. Kemudian salinan repositori asli akan muncul di akun pribadi Anda, yang menunjukkan bahwa itu adalah percabangan:Sekarang Anda dapat bekerja dengan repositori ini seperti biasa, menambahkan perubahan ke cabang master, dan ketika semuanya sudah siap, Anda dapat membuat permintaan tarik ke repositori asli. Untuk melakukannya, klik tombol Permintaan tarik baru :

Strategi mana yang harus dipilih

Git adalah alat yang fleksibel dan kuat yang memungkinkan Anda bekerja menggunakan berbagai macam proses dan strategi. Tetapi semakin banyak pilihan yang Anda miliki, semakin sulit untuk memutuskan strategi mana yang akan dipilih. Jelas bahwa tidak ada jawaban tunggal untuk semua orang. Semuanya tergantung pada situasinya. Yang mengatakan, ada beberapa pedoman yang dapat membantu dengan ini:

1. Sebaiknya pilih strategi yang paling sederhana terlebih dahulu. Pindah ke strategi yang lebih kompleks hanya bila diperlukan.
2. Pertimbangkan strategi yang memiliki jenis cabang sesedikit mungkin untuk pengembang.
3. Lihatlah pro dan kontra dari berbagai strategi, lalu pilih salah satu yang Anda butuhkan untuk proyek Anda.

Itu saja yang ingin saya katakan tentang strategi percabangan di Git. Terima kasih atas perhatian Anda :) Ikuti saya di GitHub , tempat saya sering memposting kreasi saya yang melibatkan berbagai teknologi dan alat yang saya gunakan dalam pekerjaan saya.