Strategi percabangan Git untuk kode lama yang belum dirilis

Di tim kami, selain unit kerja individu (Cerita), kami memiliki tema kerja yang lebih lama (Epos). Banyak cerita menjadi epik.

Secara tradisional, kami memiliki cabang fitur untuk setiap Story, dan menggabungkan yang langsung dikuasai ketika mereka melewati QA. Namun, kami ingin mulai menahan rilis cerita yang diselesaikan dalam Epic sampai Epic dianggap "fitur selesai". Kami hanya akan merilis fitur-fitur ini untuk produksi ketika seluruh Epic ditutup. Selain itu, kami memiliki server build malam - kami ingin semua Cerita yang tertutup (termasuk yang merupakan bagian dari Epics tidak lengkap) untuk disebarkan ke server malam ini secara otomatis.

Adakah saran tentang bagaimana mengelola repo kami untuk mencapai ini? Saya telah mempertimbangkan untuk memperkenalkan "cabang epik", tempat kami menggabungkan cerita tertutup ke cabang epik terkait alih-alih langsung dikuasai, tetapi kekhawatiran saya adalah:

Saya khawatir tentang konflik gabungan yang mungkin muncul jika cabang epik tetap terbuka lama
Bangun malam akan membutuhkan penggabungan semua cabang epik menjadi cabang "bangun malam". Sekali lagi, menggabungkan konflik dapat muncul, dan ini harus dilakukan secara otomatis

— Sitati
sumber

Jawaban:

Saran sederhana: jangan lakukan itu.

cabang git bukan untuk fork jangka panjang dari kode, seperti yang dibahas di sini dan https://blog.newrelic.com/2012/11/14/long-running-branches-considered-harmful/ . Cabang terbaik diperlakukan sebagai hal sementara yang digunakan untuk mengatur komitmen oleh pengembang individu pada tingkat sehari-hari. Jadi jika mereka memiliki nama yang sesuai dengan sesuatu yang manajer proyek (apalagi pengguna akhir) mungkin pedulikan Anda melakukan sesuatu yang salah.

Praktik yang disarankan adalah menggunakan integrasi terus-menerus dengan fitur toggle atau branch-by-abstraction untuk memastikan bahwa:

semua kode terintegrasi setiap saat (setidaknya setiap hari, lebih disukai lebih sering)
apa yang dikerahkan adalah di bawah kendali eksplisit.

— soru
sumber

Saya menduga ini mungkin jawaban populer! Kekhawatiran utama saya dengan hal ini adalah overhead dari selalu mempertahankan implementasi 'live' dan 'next', dan itu juga mensyaratkan bahwa dev yang bekerja pada fitur tahu di muka untuk membuat perubahan sebagai fitur paralel baru alih-alih meningkatkan (/ mengganti) fungsi yang ada. Tebak itu panggilan untuk perubahan pola pikir yang lebih besar dalam tim.

— Sitati

Tidak masalah menggunakan cabang untuk mengembangkan kode, hanya saja tidak pernah menggunakannya untuk menyimpan kode. Jadi, jika Anda tidak yakin apakah tugas diperbaiki 30 menit atau pengerjaan ulang 2 minggu, maka mulailah dari cabang. Segera setelah Anda tahu, baik menggabungkan atau refactor ke abstraksi / beralih kemudian bergabung.

— soru

@ Satati: Saya baru saja menggabungkan beberapa kode yang ada di cabang fitur selama empat bulan terakhir. Sementara itu pada develkami telah beralih ke CMake dari Autotools, telah memperkenalkan Travis CI, kode ulang. Pada akhirnya lebih mudah untuk memahami fitur baru dan menerapkannya secara manual develdaripada mencoba untuk menggabungkannya. Kami juga meminta siswa Master baru untuk mengembangkan fitur baru di cabang yang mereka cabut ketika mereka memulai tesis mereka. Setelah satu tahun mereka mendorongnya dan tidak ada upaya untuk mendapatkannya kembali, jadi semakin sulit untuk bergabung hari demi hari.

— Martin Ueding

Posting blog yang terhubung sekarang berusia 5 tahun. Saya benci fitur matikan. Apa yang salah dengan bercabang jangka panjang, secara teratur menggabungkan kembali ke cabang fitur dari utama, dan menambahkan integrasi berkelanjutan ke cabang fitur jangka panjang?

— Jason Kelley

CI adalah nama suatu proses, bukan alat. Jika Anda memiliki lebih dari satu cabang fitur, mereka biasanya tidak akan terus terintegrasi satu sama lain. Yang berarti menemukan masalah lebih cepat daripada lebih cepat.

— soru

Saya pikir ini adalah masalah yang cukup umum dan bermuara pada memilih fitur yang akan disertakan dalam rilis setelah fitur dikodekan daripada sebelumnya.

misalnya.

Saya memiliki fitur A, B dan C untuk v2 produk saya. B dan C terkait, saya tidak ingin melepaskan B kecuali C juga selesai.

Saya memiliki tiga pengembang semua bekerja pada saat yang sama pada fitur-fiturnya.

Saya Memiliki satu set tanggal rilis batu D

B selesai dan bergabung, A selesai dan bergabung. C ditunda ... apa yang harus saya lakukan ?!

Saya tidak percaya ada solusi teknis untuk masalah ini. Anda ingin merilis versi produk yang belum diuji dengan hanya menyertakan fitur A. Kecuali jika Anda menggabungkan dan menguji semua kemungkinan kombinasi fitur, ini akan selalu menjadi kemungkinan.

Solusinya lebih manusiawi. Anda telah melewatkan tanggal rilis Anda dan harus mendorongnya kembali.

— Ewan
sumber

Ini adalah masalah yang sulit tetapi satu yang dihadapi banyak orang. Saya lebih suka menggunakan pengaturan Gitflow sebagai titik awal.

Pengembangan -> Hal-hal baru sedang dikerjakan pada
Guru -> Barang-barang jadi yang membutuhkan pengujian Produksi -> Barang-barang yang telah diterbitkan untuk produksi.

Pada fitur minor (lebih pendek) saya membuat cabang dari pengembangan melakukan pekerjaan di sana kemudian menggabungkan cabang kembali ke pengembangan.

Pada fitur-fitur utama (jangka panjang) saya membuat cabang dari pengembangan, membuat cabang yang lebih kecil dari cabang itu, kemudian bergabung kembali ke cabang pertama. Setelah fitur utama selesai, lalu kembali ke cabang pengembangan.

Secara berkala (tergantung pada proyek) saya menggabungkan pengembangan kembali ke master dan siklus pengujian dimulai. Jika ada perbaikan muncul dalam pengujian mereka dilakukan di cabang utama (cabang pembantu kemudian bergabung). Dan pengembangan dapat dilanjutkan pada cabang master selama pengujian.

Kapan saja master harus digabung ke dalam pengembangan, dan pengembangan harus digabung ke salah satu dari cabang pembantu jangka panjangnya.

master harus selalu (secara teori) siap untuk produksi. Pembangunan harus selalu (secara teori) siap untuk produksi. Satu-satunya alasan ada perbedaan untuk menyediakan serangkaian fitur yang solid untuk diuji oleh penguji.

Ketika siap, komit master yang diuji digabung ke dalam produksi dan penyebaran dalam produksi terjadi dari cabang itu. HOTFIX yang perlu dilakukan dalam keadaan darurat kemudian dapat terjadi di cabang Produksi tanpa harus bergabung dalam master (yang mungkin memiliki banyak perubahan yang belum diuji).

Seperti pohon normal saya

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production

Ini adalah aturan umum saya bahwa tidak ada perubahan tunggal yang akan memakan waktu lebih dari beberapa jam. Jika ya maka perlu dibuat perubahan yang lebih kecil. Jika ini adalah fitur yang sangat besar (seperti UI menulis ulang) maka itu akan berjalan dalam jangka panjang sehingga perkembangan normal dapat berlanjut pada saat yang sama. Cabang-cabang LongTerm biasanya hanya cabang-cabang lokal sementara Development, Master, dan Production adalah cabang-cabang terpencil. Setiap cabang pembantu juga hanya lokal. Ini menjaga repositori tetap bersih untuk orang lain, tanpa menghilangkan kegunaan git pada set fitur jangka panjang.

Saya ingin mencatat, bagaimanapun, bahwa keberadaan cabang jangka panjang adalah hal yang langka. Biasanya, semua pekerjaan saya dalam pengembangan. Hanya ketika saya memiliki fitur (set) yang akan memakan waktu begitu lama sehingga saya harus dapat mengerjakan hal-hal dev yang normal juga, saya menggunakan cabang LongTerm. Jika itu hanya satu set perubahan yang harus bersama maka saya hanya tidak bergabung untuk menguasai sampai semua selesai.

— coteyr
sumber

"Pada fitur utama (jangka panjang) saya membuat cabang dari pengembangan" - tidakkah Anda harus membuat cabang (pengembangan) fitur baru dari cabang Produksi? Melihat sebagai cabang Produksi adalah kode siap rilis.

— robotron

Tidak, produksi sudah dirilis, master di depan produksi dan pengembangan di depan master. Fitur baru seperti menambahkan pajak ke total pesanan tidak ada gunanya jika Anda tidak bekerja pada kode yang sudah memiliki pesanan.

— coteyr

Tetapi jika Anda bercabang dari dev dan kemudian bergabung kembali bukankah cabang itu (dan akibatnya, menguasai dan Produksi nanti) kemudian menggabungkan semua perubahan dev yang dibuat oleh orang lain hingga titik percabangan? Beberapa dari perubahan itu mungkin tidak memiliki persetujuan QA. Mungkin sedang berbicara tentang berbagai pendekatan untuk melepaskan manajemen.

— robotron

Ya itu akan, itu intinya. QA menguji pada SHA master tertentu, tetapi Anda tidak tahan untuk itu.

— coteyr

"QA menguji pada SHA master tertentu" -> QA menguji setiap fitur baru sebagai standalone? Biarkan saya menjalankan skenario khas yang dihadapi tim saya: katakan Anda memiliki 2 proyek yang berjalan lama pada basis kode yang sama: Proyek A ada di QA selama sebulan terakhir dan akan QA di bulan lain. Proyek B sedang dalam pengembangan selama 6 bulan terakhir dan sekarang siap untuk QA. Proyek A digabung menjadi master dan jelas tidak siap untuk produksi karena berbagai kesalahan aturan bisnis yang halus. Bagaimana kita menangani Proyek B? A dan B harus diuji bersama untuk memeriksa interaksi (B tidak akan menyebabkan konflik selama penggabungan).

— robotron