Alur kerja Git yang sesuai untuk beberapa rilis aktif saat menangani perbaikan terbaru

Saya mencoba memilih alur kerja Git yang paling sesuai untuk produk kami. Berikut adalah parameternya:

• Kami melakukan beberapa rilis besar setahun, misalkan paling banyak 10
• Kami memiliki beberapa versi produk kami yang aktif secara bersamaan (beberapa orang menggunakan v10.1, beberapa menggunakan v11.2, dll.)
• Kita harus dapat mengerjakan beberapa rilis sekaligus (jadi kita bisa mengerjakan v12.1, tetapi ketika kita sampai pada akhir rilis kita mulai mengerjakan v12.2 pada saat yang sama)
• Kita harus dapat memperbaiki rilis saat bug penting ditemukan

Sejauh ini, menurut saya cara ini bisa berhasil:

• Repo jarak jauh tunggal digunakan
• Buat cabang 12.1 dari master
• Buat cabang fitur berdasarkan 12.1, komit dan gabungkan kembali ke 12.1, tekan
• Setelah kami perlu mulai bekerja pada rilis mendatang, buat cabang baru 12.2 berdasarkan 12.1
• Sejak saat itu, ketika mengerjakan fitur untuk 12.1, buat cabang dari 12.1, komit perubahan, dan gabungkan menjadi 12.1 dan 12.2, tekan
• Jika mengerjakan fitur untuk 12.2, buat cabang dari 12.2, komit perubahan, dan gabungkan hanya menjadi 12.2, tekan
• Ketika rilis 12.1 selesai, gabungkan menjadi cabang master dan tag master dengan 12.1
• Jika perbaikan terbaru diperlukan, buat cabang perbaikan terbaru dari cabang rilis terlama yang membutuhkannya, komit perubahan, dan gabungkan kembali ke semua cabang rilis untuk rilis itu dan rilis mendatang yang bisa dipengaruhi; jika cabang rilis stabil terbaru terpengaruh, gabungkan menjadi master.

Saya punya beberapa masalah:

• Saya tidak yakin menggabungkan hotfix dari cabang lama ke cabang baru akan menjadi proses yang lancar, terutama jika ada banyak perubahan yang tumpang tindih; apakah akan lebih pintar untuk hanya perbaikan terbaru secara manual di setiap cabang dalam kasus di mana sepertinya akan ada konflik
• Model alur kerja yang saya lihat tampaknya tidak membuat cabang rilis tetap hidup, setelah selesai rilis akan digabung menjadi master, ditandai, dan dihapus. Masalah saya dengan itu adalah bahwa saya tidak punya ide bagus bagaimana mengelola keadaan rilis jika semua yang saya miliki adalah tag in master, tampaknya lebih mudah untuk memperbaiki hotfix di cabang dan kemudian saya memiliki rilis saya selalu dapat kembali ke yang memiliki perbaikan terbaru (saya bahkan dapat menandai perbaikan terbaru di rilis). Tidak yakin ada cara saya bisa kembali dalam master dan entah bagaimana memiliki salinan rilis dengan perbaikan terbaru yang diterapkan dan memperbarui tag itu.

Komentar dihargai pada hal-hal yang mungkin saya abaikan atau cara yang lebih baik untuk mencapai hal-hal yang diberikan persyaratan yang saya tentukan.

Anda tampaknya bercabang di setiap rilis utama (12.0.0), kemudian memiliki kemungkinan pembaruan kecil untuk masing-masing (12.1.0), dan perbaikan terbaru (12.2.1). Benar?

Tidak ada alasan khusus mengapa Anda tidak bisa membiarkan cabang rilis tetap hidup di GitFlow setelah rilis, selain fakta bahwa mengkoordinasikan perubahan antara beberapa cabang yang berbeda untuk waktu yang lama sulit dengan model apa pun. Saya kira GitFlow juga dimodelkan lebih banyak untuk produk yang mempertahankan rilis langsung tunggal sambil mengembangkan yang berikutnya.

Saya akan tetap dengan GitFlow dan membuat beberapa amandemen;

Lewati cabang utama. Sejauh ini saya belum pernah menggunakannya secara praktis, dan itu akan kehilangan linearitasnya seperti cara Anda bekerja. Pertahankan pengembangan pada rilis utama berikutnya pada pengembangan. Jika Anda memutuskan untuk tetap menjadi master, jangan letakkan tag rilis pada master, letakkan di komit terakhir pada cabang rilis yang menghasilkan biner yang Anda kirim.

Jangan membuang cabang rilis setelah Anda menggabungkannya kembali untuk berkembang. Alih-alih menjaga mereka di sekitar untuk rilis kecil berikutnya dan kemungkinan perbaikan panas. Jika Anda pernah berhenti mendukung rilis, saya rasa tidak apa-apa untuk menghapusnya. Anda bisa memberi nama cabang rilis setelah komponen utamanya, rilis / 12, dan kemudian buat cabang sub-rilis, lepas / 12.1, lepas / 12.2. Saya tidak perlu terlalu khawatir tentang tingkat paralelisme ini, tetapi mungkin itulah yang saya coba. Anda dapat menganggap setiap cabang rilis utama sebagai lingkungan sub-GitFlow sendiri dalam kasus ini.

Jika Anda harus bekerja secara paralel pada fitur-fitur untuk beberapa rilis utama masa depan pada saat yang sama, mungkin Anda harus terus mengembangkan yang berikutnya (13) dan apa pun untuk versi yang lebih baru (14, 15) pada cabang-cabang "develop-N" tambahan . Itu tampaknya sangat sulit untuk dipertahankan secara umum, tetapi mungkin saja dilakukan.

Tampaknya solusi yang mungkin untuk masalah utama Anda ( «Kami harus dapat bekerja pada beberapa rilis pada saat yang sama [...]» ) sedang melakukangit worktree add <path> [<branch>]

Repositori git dapat mendukung banyak pohon yang berfungsi , memungkinkan Anda untuk memeriksa lebih dari satu cabang sekaligus.
Dengan git worktree add, pohon kerja baru dikaitkan dengan repositori.

Pohon kerja baru ini disebut "pohon kerja tertaut" sebagai lawan dari "pohon kerja utama" yang disiapkan oleh " git init" atau " git clone" .
Repositori memiliki satu pohon kerja utama (jika itu bukan repositori kosong) dan nol atau lebih pohon kerja yang ditautkan.

Lihat jawaban SO ini untuk pengantar rinci pada git worktree.

Anda menyebutkan bahwa Anda terbiasa dengan gitflow. Saya sarankan untuk menambahkannya untuk skenario Anda. Anda perlu membuat cabang dari cabang pengembangan Anda untuk mendukung versi yang lebih lama. Versi yang lebih lama ini juga harus memiliki cabang rilis / master dan cabang perbaikan terbaru. Anda perlu menggabungkan cabang dukungan secara berkala ke cabang dukungan yang lebih baru dan mengembangkan cabang.

Seiring perkembangan versi-versi utama yang menyimpang ini akan terus semakin sulit. Tidak ada peluru perak untuk ini. Terkadang akan lebih mudah untuk melakukan perubahan secara manual. Biaya pemeliharaan versi yang lebih lama akan meningkat, dan pada titik tertentu itu tidak layak lagi.

Itu semua tergantung pada jenis perubahan apa yang Anda buat di versi lama. Jika hanya perbaikan bug, itu relatif mudah untuk digabungkan. Jika Anda mencoba menambahkan fitur baru, itu akan sulit.