Seharusnya melepaskan cabang yang akan digabungkan menjadi master

Tim saya menggunakan model percabangan Git Stable Mainline dan kami akan membuat cabang rilis pertama. Dari apa yang telah saya baca sejauh ini, sepertinya cabang rilis dilepaskan dari cabang master dan tidak pernah sepenuhnya digabungkan kembali ke master. Sebaliknya, jika perbaikan dilakukan pada cabang rilis, maka biasanya dipetik kembali ke cabang master. Ini masuk akal bagi saya karena Anda ingin menjaga rilis saat ini benar-benar terpisah dari pengembangan rilis berikutnya, sementara masih bisa mengembangkan set fitur berikutnya pada master pada saat yang sama dengan menyiapkan rilis saat ini.

Berapa lama cabang rilis ini harus disimpan? Apakah ada kasus di mana mereka harus sepenuhnya digabungkan kembali menjadi tuan?

git release-management

Strategi percabangan yang Anda gunakan bergantung sepenuhnya pada alur kerja organisasi Anda dan persyaratan khusus.

— Robert Harvey

How long should these release branches be kept around for?Selama Anda mengharapkan untuk menerima pesan kesalahan untuk rilis yang ingin Anda reproduksi dari kode sumber. Saya tidak akan menghapus cabang rilis sama sekali karena cabang memiliki jejak kilobyte kecil di server. hanya delta yang menghabiskan memori harddisk

— k3b

cherry pickingsetiap komit pada cabang rilis ke master atau merging rilis ke master secara teknis adalah hal yang sama menerima bahwa Anda tidak "melihat" cherry picksdalam sejarah git. Jadi saya lebih suka mergingmasing-masing memperbaiki kembali ke master menggunakan --no-ffopsi gits sehingga sejarah menunjukkan cabang rilis tambahan.

— Timothy Truckle

maksud Anda ini: bitsnbites.eu/a-stable-mainline-branching-model-for-git he explicity mengatakan tidak pernah menggabungkan cabang rilis kembali

— Ewan

Terima kasih atas tanggapan semua orang. @ Ewan Ya, tapi saya juga membaca beberapa dokumentasi umum Git yang ditulis oleh Microsoft dan sepertinya mereka tidak pernah menggabungkan seluruh cabang rilis kembali untuk dikuasai juga.

Berapa lama seharusnya cabang-cabang ini disimpan?

Jawaban pertama yang muncul di pikiran saya di sini adalah:

Mengapa Anda membuat cabang rilis di tempat pertama?

Jika Anda bertujuan untuk dapat memberikan dukungan ke versi dalam penggunaan produksi, maka versi tersebut akan hidup selama versi tersebut tinggal bersama pelanggan Anda. (katakanlah dukungan LTS, Anda dapat memiliki beberapa cabang seperti itu, membuat hal-hal sedikit lebih rumit)

Jika Anda memisahkan pekerjaan stabilisasi dari pengembangan baru yang sedang berjalan maka setelah versi digunakan Anda tidak benar-benar membutuhkan cabang itu lagi. Di sini ini akan mengisyaratkan pipa pengiriman kontinu. Setiap bug mendapatkan perbaikannya pada rilis berikutnya yang akan terjadi sesering mungkin. Beberapa mendorong ini untuk mempertimbangkan cabang utama sebagai cabang stabil yang digunakan beberapa kali sehari. Orang lain akan disinkronkan ke sprint mereka dan dirilis setiap dua hingga tiga minggu.

Haruskah Anda menggabungkannya sepenuhnya menjadi master?

Seperti yang Anda duga semuanya tergantung pada mengapa Anda mengadopsi strategi percabangan ini. untuk gaya pengiriman kontinu, karena cabang tidak akan pernah digunakan lagi maka Anda harus memperlakukannya sama seperti Anda akan cabang fitur atau bugfix lainnya, kemungkinan Anda akan menggabungkannya kembali ke master dan melupakannya.

Namun jika Anda bertujuan untuk gaya LTS maka Anda kemungkinan tidak akan menggabungkannya kembali, terutama jika Anda memiliki beberapa cabang seperti itu. Di sini Anda akan menerapkan perbaikan untuk semua cabang rilis dan memilih cherry dari salah satu dari mereka untuk menggabungkan perbaikan itu di master. Dalam skenario ini, hal terakhir yang ingin Anda lakukan adalah memperlakukannya seperti cabang fitur lainnya di mana perubahan dari master ditarik ke dalamnya dan konflik diselesaikan di sana daripada di master.

Tanpa mengetahui lebih banyak tentang siklus hidup produk Anda dan alur kerja tim Anda, sulit untuk menghasilkan saran yang lebih tepat di sini.

— Newtopian
sumber

Ini menyiratkan bahwa cabang hilang setelah penggabungan, yang bukan merupakan kasus. Cabang rilis harus digabung dalam master dalam mode LTS juga. Tidak ada alasan untuk tidak menggabungkan cabang rilis.

— Basilevs

Ini bukan tentang cabang yang hilang tetapi lebih tentang memaksa orang untuk berpikir, secara sistematis menggabungkan cabang LTS akan membuat mereka menggabungkan duplikat untuk setiap cabang LTS yang aktif. Perbaikan bug hanya perlu digabungkan kembali ke induk dan kemungkinan tidak dari cabang LTS karena versi terbaru kemungkinan belum ada di LTS dan akan lebih dekat dengan keadaan cabang master. Dalam skenario ini seseorang akan memilih cherry dari versi terbaru, cabang LTS sendiri hampir tidak akan pernah didorong ke master. Bahwa cabang hilang atau tidak setelah penggabungan tidak relevan.

— Newtopian

Mengapa orang lebih suka menduplikasi cherry-picks yang tidak aman untuk menggabungkan duplikasi yang aman? Yang saya maksud dengan "aman" adalah pelacakan dan penyebaran perubahan yang dilindungi secara kriptografis.

— Basilevs

Pendekatan serupa bekerja tanpa cherry-picks dengan menerapkan perbaikan ke cabang tertua dan menggabungkan dari yang lebih tua ke yang lebih baru. Jika cherry-picks dapat dihindari mengapa menggunakannya? Saya sepertinya salah paham tentang sesuatu dalam model Stable Mainline ...

— Basilevs