Apakah perusahaan saya salah menggabungkan cabang?

28

Saya baru-baru ini menemukan sebuah artikel MSDN tentang percabangan dan penggabungan dan SCM: Branching and Merging Primer - Chris Birmele .

Dalam artikel tersebut mereka mengatakan 'big bang merge' adalah antipattern yang menggabungkan:

Big Bang Merge - menunda cabang yang bergabung ke akhir upaya pengembangan dan berusaha menggabungkan semua cabang secara bersamaan.

Saya menyadari bahwa ini sangat mirip dengan apa yang dilakukan perusahaan saya dengan semua cabang pengembangan yang diproduksi.

Saya bekerja di perusahaan yang sangat kecil dengan satu orang yang bertindak sebagai peninjau akhir + otoritas gabungan trunk. Kami memiliki 5 pengembang (termasuk saya), masing-masing dari kami akan diberi tugas / bug / proyek terpisah dan kami masing-masing akan bercabang dari trunk saat ini (subversi) dan kemudian melakukan pekerjaan pengembangan di cabang kami, menguji hasilnya, menulis dokumentasi jika perlu, lakukan peer review dan loop umpan balik dengan pengembang lain, dan kemudian kirim cabang untuk ditinjau + bergabung pada perangkat lunak manajemen proyek kami.

Bos saya, satu-satunya otoritas di repositori trunk, sebenarnya akan menunda semua ulasan cabang sampai satu titik waktu di mana ia akan melakukan review sebanyak yang dia bisa, beberapa cabang akan dilempar kembali untuk peningkatan / perbaikan, beberapa cabang akan bergabung ke dalam bagasi, beberapa cabang akan terlempar ke belakang karena konflik, dll.

Ini tidak biasa bagi kita untuk memiliki 10-20 cabang aktif yang duduk dalam antrian tinjauan akhir untuk digabung menjadi bagasi.

Kami juga sering harus menyelesaikan konflik dalam tahap peninjauan akhir dan penggabungan karena dua cabang dibuat dari trunk yang sama tetapi memodifikasi bagian kode yang sama. Biasanya kita menghindari ini dengan hanya menata kembali batang pohon dan menerapkan kembali perubahan kita dan menyelesaikan konflik kemudian mengirimkan cabang baru untuk ditinjau (orang miskin rebase).

Beberapa pertanyaan langsung yang saya miliki adalah:

Apakah kita menunjukkan pola yang sangat anti yang digambarkan sebagai 'big bang merge'?
Apakah beberapa masalah yang kita lihat adalah hasil dari proses penggabungan ini?
Bagaimana kita bisa meningkatkan proses penggabungan ini tanpa meningkatkan hambatan pada bos saya?

Sunting: Saya ragu bos saya akan melonggarkan cengkeramannya di repositori trunk, atau membiarkan pengembang lain bergabung ke trunk. Tidak yakin apa alasannya tetapi saya tidak benar-benar berencana untuk mengangkat topik karena sudah diangkat sebelumnya dan ditembak jatuh lebih cepat. Saya pikir mereka hanya tidak mempercayai kami, yang tidak masuk akal karena semuanya dilacak pula.

Wawasan lain apa pun tentang situasi ini akan dihargai.

— pengguna6567423
sumber

2

Mengapa penggabungan ditunda? Biasanya, ada alasan untuk tidak segera melakukannya. Apakah pria lajang terlalu banyak bekerja dan jaminan simpanan begitu besar? Adakah alasan lain mengapa penggabungan tidak dilakukan tepat waktu?

— Polygnome

1

Saya berada di posisi yang sama dengan Anda, beberapa kali. Saya dapat mengatakan dari pengalaman pribadi bahwa banyak perusahaan melakukan kontrol versi, terutama percabangan, sangat salah.

— MechMK1

3

Apa yang terjadi ketika bos pergi berlibur?

— Liath

Bagaimana Anda mendefinisikan strategi percabangan / penggabungan kernel linux?

— Braiam

Apakah perubahan yang dilempar ke belakang karena konflik tetapi tidak cacat lain perlu melalui proses persetujuan lagi setelah konflik diselesaikan atau apakah mereka dianggap "disetujui sementara"?

— Gregory Nisbet

60

Beberapa saran:

Tidak ada yang salah dalam memiliki banyak cabang fitur atau perbaikan bug selama perubahan yang dilakukan di masing-masing cabang cukup kecil, Anda masih dapat menangani konflik gabungan yang dihasilkan secara efektif. Itu harus menjadi kriteria Anda jika cara kerja Anda ok, bukan beberapa artikel MSDN.
Setiap kali cabang digabungkan ke dalam trunk, trunk harus digabung ke semua cabang pengembangan terbuka secepatnya. Ini akan memungkinkan semua orang dalam tim untuk menyelesaikan konflik gabungan secara paralel di cabang mereka sendiri dan karenanya mengambil beberapa beban dari penjaga gerbang bagasi.
Ini akan bekerja lebih baik jika gatekeeper tidak akan menunggu sampai 10 cabang "siap untuk bergabung ke dalam trunk" - menyelesaikan konflik penggabungan dari integrasi trunk terakhir selalu memerlukan waktu untuk tim, jadi mungkin lebih baik untuk bekerja dalam interval waktu yang terjalin. - satu integrasi oleh gatekeeper, satu re-gabung oleh tim, integrasi berikutnya oleh gatekeeper, selanjutnya re-gabung oleh tim, dan sebagainya.
Untuk menjaga agar cabang tetap kecil, mungkin membantu untuk membagi fitur yang lebih besar menjadi beberapa tugas yang lebih kecil dan mengembangkan masing-masing tugas tersebut di cabang sendiri. Jika fitur ini belum siap produksi hingga semua subtugas diimplementasikan, sembunyikan dari produksi di belakang fitur toggle hingga semua subtugas selesai.
Cepat atau lambat Anda akan menjumpai tugas-tugas refactoring yang memengaruhi banyak file dalam basis kode - ini memiliki risiko tinggi menyebabkan banyak menggabungkan konflik dengan banyak cabang. Itu dapat ditangani dengan paling baik dengan mengkomunikasikannya dengan jelas dalam tim, dan pastikan untuk menanganinya persis seperti yang saya tulis di atas: dengan mengintegrasikannya terlebih dahulu ke semua cabang dev sebelum reintegrasi, dan dengan memecahnya menjadi sub-refactor yang lebih kecil.
Untuk ukuran tim Anda saat ini, memiliki penjaga gerbang tunggal mungkin masih berfungsi. Tetapi jika tim Anda akan bertambah besar, tidak ada jalan lain untuk memiliki penjaga gerbang kedua (atau lebih). Catatan saya tidak menyarankan untuk memungkinkan semua orang bergabung ke dalam bagasi, tetapi itu tidak berarti hanya bos Anda yang mampu melakukan ini. Mungkin ada satu atau dua pengembang senior yang bisa menjadi kandidat untuk melakukan pekerjaan penjaga gerbang juga. Dan bahkan untuk ukuran tim Anda saat ini, gatekeeper kedua dapat membuat tim Anda lebih mudah untuk berintegrasi ke bagasi lebih sering dan lebih awal, atau ketika bos Anda tidak tersedia.

— Doc Brown
sumber

2

Saya pikir Anda memiliki komentar terbaik di sini, mengakui bahwa kami tidak bisa hanya membuka trunk untuk semua orang, dan bahwa tumpukan cabang kami tidak selalu selalu menjadi masalah (hanya ketika mereka bertentangan). Saya pikir Anda melakukan pekerjaan yang baik dengan menunjukkan bagaimana kita dapat mengurangi konflik dan memastikan siklus gabungan lancar, saya juga berpikir Anda sepenuhnya benar ketika Anda mengatakan kami mungkin membutuhkan penjaga gerbang lain. Terima kasih banyak atas wawasan ini!

— user6567423

@ user6567423 Hal lain yang mungkin ingin Anda pertimbangkan adalah membuat cabang untuk setiap versi pengembangan (mis. 5.2.3 atau apa pun), bahwa setiap pengembang dapat bercabang untuk pekerjaan fitur dan kemudian bergabung, dan yang kemudian dapat digabungkan kembali ke utama lepaskan cabang oleh bos saat pengembangan selesai.

— nick012000

@ nick012000: apakah saran itu tidak mempersulit penjaga gerbang untuk menerima atau menolak cabang fitur individual untuk / terhadap integrasi ke dalam trunk? Maksud saya, jika beberapa fitur digabung menjadi satu cabang pengembangan, reintegrasi sebagian perubahan itu menjadi batang akan menjadi sangat sulit. Atau apakah saya melewatkan sesuatu?

— Doc Brown

10

" menyelesaikan konflik penggabungan secara paralel di cabang mereka sendiri dan karenanya mengambil beberapa beban dari penjaga gerbang bagasi. " - Saya merasa seperti bagian ini dikurangi secara adil menjadi catatan samping. "Itu lebih baik untuk perusahaan TETAPI JUGA lebih mudah untukmu " sepertinya titik penjualan utama ketika menyarankan ini kepada bos. Itu lebih mengarah ke politik kantor arah, yang SE bukan tentang - tetapi dalam situasi ini, tanpa buy-in dari bos, segala sesuatu dalam jawaban yang sangat baik secara teknis ini tidak akan terjadi.

— R. Schmitz

@DocBrown Ya, itu akan, tetapi itu juga berarti bahwa Anda akan memiliki lebih sedikit konflik antara cabang-cabang dev dan itu masih akan memberi Anda tingkat keamanan yang diberikan dengan tidak langsung bergabung ke cabang utama - dan dia hanya bisa menolak untuk menerima pekerjaan sebagai Selesai dan melakukan penggabungan hingga dia puas dengan status kode secara keseluruhan.

— nick012000

18

Apakah kita menunjukkan pola yang sangat anti yang digambarkan sebagai 'big bang merge'?

Kedengarannya seperti itu.

Apakah beberapa masalah yang kita lihat adalah hasil dari proses penggabungan ini?

Pastinya

Bagaimana kita bisa meningkatkan proses penggabungan ini tanpa meningkatkan hambatan pada bos saya?

Di perusahaan saya, setiap pengembang memiliki kemampuan untuk bergabung. Kami memberikan Permintaan Gabung ke pengembang lain, menjalani siklus peninjauan / umpan balik / pembaruan hingga kedua pihak puas. Kemudian pengulas menggabungkan kode.

10-20 cabang menunggu untuk digabung adalah tanda bahwa proses Anda cacat. Jika kita memiliki sebanyak itu, semua pekerjaan dev akan berhenti sampai selesai.

— Matius
sumber

1

Bukan jawaban yang saya cari karena saya ragu bos saya akan melonggarkan cengkeramannya di repositori trunk. Tapi jawaban yang luar biasa membantu, terima kasih atas wawasannya!

— user6567423

5

@ user6567423: Jika bos Anda menjadi penghambat, yang sekarang sesuai dengan deskripsi Anda, ia harus mengubah pendekatannya atau menerima bahwa dialah penyebab keterlambatan (yang tidak dapat disalahkan oleh karyawannya). Menolak mengubah pendekatan Anda, mengabaikan masalah yang Anda ciptakan, dan menyalahkan orang lain bukanlah cara menjalankan bisnis.

— Flater

1

Dia setuju bahwa dia adalah hambatan dan dia pasti tidak menyalahkan orang lain untuk itu. Tapi ya, saya sedang mencari tips yang mungkin tidak jelas yang mungkin dapat mengurangi hambatan kami. Terima kasih atas wawasannya

— user6567423

1

@ user6567423 Saya ingin tahu apakah dia pernah menjelaskan mengapa dia satu-satunya yang dapat bergabung ke trunk.

— Matius

13

Ini pada dasarnya adalah bagaimana banyak proyek open source bekerja, termasuk yang paling terkenal adalah kernel Linux, yang memiliki banyak cabang dalam penerbangan daripada yang Anda lakukan pada waktu tertentu. Cara khas untuk menghindari penggabungan big bang dalam proyek ini adalah membuat cabang lain (atau banyak cabang) untuk integrasi berkelanjutan. Ini adalah cabang yang Anda gunakan untuk memastikan perubahan Anda bekerja sama dengan kolega Anda, dan itu diubah secara berkala ke bagasi ketika gatekeeper sempat melakukan review.

Secara opsional, Anda dapat menggunakan cabang ini untuk menggabungkan beberapa permintaan tarik Anda sendiri menjadi satu permintaan kohesif besar bagi bos Anda untuk ditinjau. Linus Torvalds biasanya mendapat permintaan tarikan yang telah terintegrasi dalam dua atau lebih level, dan dapat memiliki ukuran pada urutan, misalnya, driver sistem file baru yang lengkap.

— Karl Bielefeldt
sumber

Terima kasih, saya pikir tips untuk menggabungkan cabang dan mencegah konflik mungkin akan menjadi tindakan terbaik kami.

— user6567423

8

Saya setuju dengan kedua Doc Brown tetapi saya juga melihat antipattern lain:

Bos saya, satu - satunya otoritas di repositori trunk , sebenarnya akan menunda semua ulasan cabang sampai satu titik waktu di mana ia akan melakukan review sebanyak yang dia bisa, beberapa cabang akan dilempar kembali untuk peningkatan / perbaikan, beberapa cabang akan bergabung ke dalam bagasi, beberapa cabang akan terlempar ke belakang karena konflik , dll.

Dalam kerendahan hati saya, ada beberapa antipattern manajemen:

Ia adalah satu-satunya titik tersedak yang membatasi kecepatan tim. Faktor bus Anda adalah 1. Teori kendala mengatakan bahwa Anda harus berupaya meningkatkan bagian rantai yang paling lambat.
Manajer Anda membuat siklus umpan balik Anda lebih lambat dan mengurangi kelincahan tim Anda. Bisakah Anda melepaskannya setiap minggu?
Menggabungkan kompleksitas tumbuh secara eksponensial dengan jumlah kode. Lebih baik membuat 10 penggabungan dengan 100 garis daripada 1 dari 1000 garis. Itulah salah satu alasan mengapa Anda harus melakukannya SECEPATNYA
Jika Anda mendeteksi kegagalan di bagasi Anda akan melakukannya pada waktunya. Yang mana dari beberapa cabang yang bermasalah
Keputusan harus dibuat oleh mereka yang memiliki lebih banyak pengetahuan tentang mereka. Siapa yang tahu lebih banyak dalam hal ini? Saya bertaruh bahwa pengembang yang membuat kode.
Anda tidak dapat memperbaiki bug dalam produksi jika manajer Anda ada di holydays.
Anda mengulang pekerjaan dan melemparkan kembali cabang. Ini buang - buang waktu. Waktu menunggu untuk mencapai produksi juga merupakan pemborosan.

Rekomendasi:

Manajer Anda perlu mendelegasikan tanggung jawab kepada tim. Anda perlu menunjukkan bahwa tim tersebut matang, profesional. Jelaskan bahwa mereka dapat mempercayai tim
Terapkan beberapa metode ulasan. Mungkin Anda membutuhkan persetujuan dua anggota tim lainnya.
Mungkin menggunakan SVN membuatnya lebih sulit. Cobalah Git dan lihat apakah itu membantu Anda. Bahkan lebih. Jika Anda menggunakan GitHub, Anda dapat menggunakan mekanisme Tarik Permintaan sehingga penggabungan membutuhkan suara tertentu.
Baca dan bagikan informasi tentang praktik lincah, integrasi berkelanjutan, dan DevOps.

— Borjab
sumber

7

Saya telah bekerja secara profesional dengan SVN dan git, dan saya akan mengatakan bahwa SVN jelas merupakan bagian dari masalah: Ini memaksa kebijakan satu-gabungan-kembali komitmen pada cabang yang tidak ada dalam git. Dalam git, semua gabungan sama, dalam SVN, beberapa lebih sama daripada yang lain. Juga, kurangnya komitmen lokal membuatnya jauh lebih sulit untuk bereksperimen dengan SVN daripada dengan git, dan kurangnya zona pementasan hanya menambah ketidakfleksibelan SVN. Ada alasan mengapa Torvalds tidak hanya menggunakan SVN daripada mengembangkan git ...

— cmaster

Git jauh lebih baik daripada svn menurut saya untuk alasan @cmaster ditata dan banyak lagi

— reggaeguitar

Saya setuju git mungkin akan menyelesaikan beberapa masalah penggabungan kami, dan Tuhan yang terkasih, saya ingin memiliki rebase tersedia. Tapi saya tidak berpikir kita akan segera beralih :(

— user6567423

1

@ user6567423, saya melakukan konsultasi tahun lalu di mana saya membantu transisi tim kecil dari svn ke Git dan mengubah alur kerja mereka, termasuk melatih mereka tentang Git dan mengaturnya dengan edisi komunitas GitLab (yang merupakan sumber terbuka) untuk ulasan kode dan kolaborasi . Mereka sangat antusias tentang hal itu; perbedaan malam dan siang. (Juga hanya butuh tiga hari.)

— Wildcard

2

Saat Anda melakukan pekerjaan fitur di cabang-cabang terpisah, Anda tidak dapat dengan mudah melakukan pengujian integrasi sampai salah satu cabang digabungkan ke bagasi dan ditarik ke cabang fitur lainnya. Dalam pengalaman saya, ini adalah masalah utama dengan anti-pola Big Bang Merge. Idealnya, Anda akan melakukan kerja fitur, mengujinya di cabang fitur, menggabungkannya ke dalam trunk, dan pada saat itu Anda selesai dengan fitur tersebut. Jika belum digabung, Anda harus mengunjungi kembali setiap kali ada yang lain digabungkan ke dalam trunk sebelumnya. Kelemahan dari pola-anti ini adalah Anda memiliki banyak bug tipe integrasi yang muncul di akhir siklus pengembangan.

— bmm6o
sumber

1

Jadi, Anda memiliki 20 cabang. Cabang 1 baru saja digabung. Kemudian pengembang cabang 2 harus menggabungkan cabang 1 ke cabang mereka untuk dapat bergabung menjadi utama tanpa konflik, kemudian bergabung. Kemudian pengembang cabang 3 harus menggabungkan cabang 1 dan cabang 2 ke cabang mereka untuk dapat bergabung menjadi utama tanpa konflik, kemudian bergabung.

Latihan untuk pembaca: Menulis program yang mencetak posting lengkap saya :-)

Ini adalah kegilaan. Anda akan menghabiskan banyak waktu untuk menggabungkan.

— gnasher729
sumber

Yah belum tentu, kecuali cabang-cabang dalam konflik maka dia bisa menggabungkan semuanya menjadi batang mulus. Kami biasanya akan mencoba untuk mencegah konflik dengan melakukan tes gabungan sebelum kami menyerahkan cabang untuk ditinjau tetapi konflik muncul tak terhindarkan karena jumlah cabang dalam antrian meningkat. Saya setuju bahwa itu terdengar seperti kegilaan.

— user6567423

2

Perilaku penggabungan SVN yang normal, sejauh yang saya tahu ...

— cmaster

0

Mengingat cara Anda bekerja dan bahwa bos Anda adalah orang yang memegang kendali yang bertanggung jawab, percabangan itu sendiri tampaknya menjadi masalah. Alih-alih membuat cabang untuk setiap fitur, mintalah setiap pengembang mengkomit fitur-fiturnya di bagian, langsung ke bagasi. Ini menempatkan beban integrasi pada pengembang dalam beberapa langkah kecil (win-win). Penjaga gerbang dapat mengikuti pelacakan perubahan yang lebih kecil dalam periode yang lebih lama di awal siklus pengembangan dan masih menjadi master reviewer.

Bercabang sendiri adalah sesuatu yang tidak ingin Anda lakukan kecuali Anda memiliki alasan yang sangat baik untuk melakukannya atau Anda tidak memiliki pilihan lain. Anda cukup kecil untuk menyelaraskan berbagai hal, yang akan lebih mudah dan aman.

— Martin Maat
sumber

1

Dan bagaimana Anda akan menangani rilis jika hanya satu dari fitur-fitur tersebut memiliki bug atau belum selesai tepat waktu? "Bercabang itu sendiri adalah sesuatu yang tidak ingin Anda lakukan kecuali Anda memiliki alasan yang sangat bagus untuk melakukan" - Setelah Anda memiliki 5 orang yang bekerja pada beberapa fitur masing-masing, Anda harus menggunakan percabangan kecuali Anda memiliki alasan yang sangat sangat baik untuk tidak melakukannya.

— Ivo van der Veeken

Itu tentang dua hal: bos ingin tetap menjadi satu-satunya penjaga pintu dan hal-hal yang seharusnya tidak terlalu menyimpang. Ya, akan ada saat di mana sesuatu didorong yang belum diteliti oleh bos. Dia harus dapat melakukan itu dengan cepat dan jika tidak mungkin dia harus segera mengirimkannya, dia dapat mengembalikan komitmen terbaru. Ini akan menjaga semuanya tetap sinkron dan jika Anda gagal dalam hal apa pun Anda pasti akan gagal dengan cepat. Sepertinya kompromi yang baik bagi saya untuk situasi yang dihadapi.

— Martin Maat

1

Saya akan menganggap ini sebagai upaya terakhir

— reggaeguitar