Kecenderungan cabang “berkembang” hilang

82

Saya telah memperhatikan sesuatu belakangan ini melihat beberapa proyek populer di GitHub, bahwa tidak ada developcabang. Dan pada kenyataannya, panduan GitHub Flow tidak menyebutkannya juga. Dari pemahaman saya, masterharus selalu benar-benar stabil dan mencerminkan produksi. Jika pengembang bekerja pada cabang fitur, dan kemudian menggabungkannya ke dalam masterketika mereka selesai, itu berarti ada periode waktu di mana fitur / perbaikan sedang digabungkan ke dalam masterdan mastercabang sebenarnya lebih baru dari produksi.

Bukankah lebih masuk akal untuk membuat tim membuat fitur / memperbaiki cabang develop, bergabung kembali ke dalamnya , dan kemudian ketika versi berikutnya benar-benar siap untuk rilis, developdigabungkan ke dalam masterdan tag dibuat? Bayangkan jika orang bergabung langsung master, dan bug dilaporkan dalam produksi yang menjadi sulit diperbaiki karena masterbasis kode cabang telah berubah secara signifikan. Kemudian para devs hanya perlu memberitahu pengguna untuk menunggu sampai rilis berikutnya untuk melihat masalah terselesaikan.

EDIT: Pertanyaan ini berbeda dari "ke cabang atau tidak ke cabang". Ini secara khusus membahas orang-orang yang pindah dari menggunakan cabang pengembangan dan alasan di sekitarnya, karena itu disebut-sebut sebagai praktik terbaik untuk waktu yang lama.

git github

— ffxsam
sumber

11

Ada banyak kemungkinan alur kerja yang memungkinkan git. Orang seharusnya tidak mengharapkan gitflow atau aliran github digunakan untuk semua proyek.

Pertanyaan yang sangat menarik. Saya telah bekerja bertahun-tahun dengan nvie.com/posts/a-successful-git-branching-model dan saya harus mengatakan bahwa saya menyukainya. Apa yang paling saya sukai tentang itu adalah: a) master adalah apa yang sedang diproduksi dan yang berlaku juga untuk versi dan b) ada perbedaan yang jelas antara perbaikan terbaru dan fitur, mereka dimulai dan digabungkan pada master dan mengembangkan masing-masing. Namun, setelah mengikuti diskusi ini saya mulai ragu apakah ini terlalu rumit. Ada pendapat tentang itu?

— Aspasia

1

Saya benci konsep bahwa master adalah rekaman dari apa yang ada di produksi. Jika kita perlu tahu apa yang ada di dalam produksi, kita seharusnya hanya meminta produksi dan tidak bergantung pada master yang secara akurat mencerminkan apa yang ada dalam produksi.

— Jim V

52

Itu berasal dari pola pikir CI di mana ada integrasi beberapa kali sehari.

Ada pro dan kontra dari keduanya.

Di tim kami, kami telah meninggalkan cabang pengembangan juga karena kami merasa itu tidak memberikan manfaat tambahan selain beberapa kekurangan. Kami telah mengkonfigurasi perangkat lunak CI kami (Teamcity) untuk mengkompensasi kekurangannya:

Aktifkan penerapan komit tertentu. Dengan kata lain: Kami tidak menyebarkan cabang. Kami menggunakan komit.
Kami dapat menggunakan master atau cabang yang dimulai dengan hotfix / awalan.

Alasan ini berfungsi adalah karena semua permintaan tarik mengandung kode yang berpotensi dapat dirilis tetapi ini tidak berarti kami menyebarkan semua komit secara master.

Alasan utama kami meninggalkan cabang pengembangan adalah karena ia cenderung menjadi terlalu besar dan terlalu memakan waktu untuk melihat apa yang sebenarnya terkandung di dalamnya. Jika kami telah menerapkan sesuatu yang sedikit sebelum waktunya, kami hanya cabang dari cabang perbaikan terbaru dan menyebarkannya secara langsung.

— Esben Skov Pedersen
sumber

11

Setelah bekerja dengan cabang pengembangan selama satu atau dua tahun, hanya untuk menggabungkannya menjadi master setiap saat, saya bisa mengatakan: amin, tinggalkan hal itu:]

— stijn

Menarik. Jadi saya berasumsi ketika Anda merilis versi 1.3 misalnya, Anda menandai komit tertentu pada master, jadi Anda jika bug muncul kemudian saat masterdalam keadaan fluks, Anda dapat dengan mudah memisahkan perbaikan terbaru dari tag 1.3?

— ffxsam

5

Saya akan mengatakan manfaat dari "mengembangkan" sangat tergantung pada jenis perangkat lunak yang Anda buat, bagaimana itu digunakan, dan apakah Anda perlu mendukung beberapa versi langsung atau tidak.

— axl

1

@ fffsam kita bahkan tidak perlu memberi tag karena kita melacak id git mana yang saat ini digunakan. Ini login di kedua TeamCity dan bercabang ke dll yang digunakan dan di portal manajemen biru. Jadi kami belum merasakan perlunya penandaan lebih lanjut kecuali dari penandaan otomatis yang dilakukan oleh TeamCity. Jika Anda merasa penandaan cocok Anda bekerja aliran lebih baik juga akan menyelesaikannya dengan baik. Tapi ya, pada prinsipnya cabang langsung dari perubahan yang saat ini digunakan untuk membuat cabang perbaikan terbaru.

— Esben Skov Pedersen

25

Kembangkan cabang lebih penting jika proses Anda untuk merilis rumit dan Anda perlu memiliki kandidat rilis yang serius.

Misalnya, bayangkan Anda sedang menulis perangkat lunak yang merupakan firmware pada mobil. Ini adalah ... non-sepele untuk diperbaiki dan kemungkinan rilis apa pun akan memiliki serangkaian uji non-CI / integrasi komprehensif yang dijalankan pada perangkat keras nyata.

Dalam hal itu mungkin lebih masuk akal untuk mengisolasi "kandidat pelepas" di cabang non-master (seperti "berkembang"). Itu memungkinkan tim Anda menjalankan tes tersebut untuk memiliki cabang untuk menggabungkan fitur.

Webapps atau perangkat lunak lain yang mudah diperbarui tidak memiliki batasan ini.

Namun, perhatikan bahwa:

Banyak (kebanyakan?) Proyek di github tidak memiliki kendala semacam ini
"Master" utama memiliki tujuan yang sama
Alur kerja "buat PR vs master" jauh lebih universal daripada "buat PR melawan cabang yang tidak Anda ketahui segera di repo ini"

— enderland
sumber

18

Ada dua filosofi yang pernah saya lihat di proyek, dan saya pikir pilihannya hanya masalah selera:

Tunjuk 'master' sebagai rilis produksi dan kembangkan di cabang 'kembangkan'.
Berkembang di 'master' dan memiliki cabang dengan nama berbeda untuk rilis produksi yang stabil. Ini lebih masuk akal jika proyek Anda memiliki beberapa cabang rilis sekaligus (mis., Yang saat ini disukai adalah Rilis-1.8, tetapi Anda juga masih mempertahankan Rilis-1.7).

Keduanya merupakan pendekatan umum, dan memiliki pro dan kontra.

— Larry Gritz
sumber

Saya setuju denganmu. Kami lebih suka memiliki cabang rilis dan mempertahankan cabang-cabang di sekitar sampai rilis berikutnya untuk produksi. Jika kita harus membuat hot-fix, kita checkout cabang rilis terakhir dan mengerjakannya, kemudian menggabungkan hot-fix itu menjadi master / mengembangkan cabang

— Johnny

Persis. Yang harus dilakukan 'master' sebagian besar adalah semantik. Hal mendasar untuk mendapatkan yang benar adalah menghindari keharusan menjaga beberapa cabang yang hidup selamanya disinkronkan secara dua arah kecuali Anda memiliki alasan yang sangat bagus untuk melakukannya. Cabang 'master' di Git Flow hanyalah replika 'berkembang' yang tertinggal, sehingga tidak terlalu diperhitungkan. Anti-pola memungkinkan cabang pengembangan utama untuk mengadakan perubahan yang tidak pernah masuk ke rilis, yang merupakan praktik mengejutkan yang pernah saya lihat. Kedua model yang disebutkan di atas mencegah hal ini, itulah sebabnya mereka bekerja.

— John Michelau

7

Rilis untuk produksi dapat ditandai, sehingga situasi yang dirilis selalu dapat direproduksi tanpa mengabdikan seluruh cabang untuk tujuan ini.

Jika bug kritis ditemukan dalam produksi pada saat master tidak dapat dirilis, maka cukup mudah untuk checkout tag dan memulai cabang "hotfix-for-release-1.2.0" baru dari sana. Tapi itu seharusnya agak jarang.

Sebagian besar waktu dalam aplikasi web kami, master telah berubah sejak rilis terakhir tetapi tidak terlalu signifikan, jadi kami hanya dapat melakukan rilis baru dari master yang memiliki perbaikan. Ini membantu untuk melakukan rilis yang sangat sering.

— RemcoGerlich
sumber

5

Jika pengembang bekerja pada cabang fitur, dan kemudian menggabungkannya menjadi master setelah selesai, itu berarti ada periode waktu di mana fitur / perbaikan sedang digabungkan ke dalam masterdan mastercabang sebenarnya lebih baru dari produksi.

...

Bayangkan jika orang menggabungkan langsung ke master, dan bug dilaporkan dalam produksi yang menjadi sulit untuk diperbaiki karena basis kode cabang master telah berubah secara signifikan.

Itu bukan Github Flow.

Ini adalah proses penyebaran / penggabungan Github Flow, sesuai dengan tautan Anda:

Menyebarkan

Setelah permintaan tarik Anda ditinjau dan cabang melewati tes Anda, Anda dapat menggunakan perubahan Anda untuk memverifikasinya dalam produksi. Jika cabang Anda menyebabkan masalah, Anda dapat mengembalikannya dengan menggunakan master yang ada ke dalam produksi.

Menggabungkan

Sekarang setelah perubahan Anda telah diverifikasi dalam produksi, sekarang saatnya untuk menggabungkan kode Anda ke cabang master.

(Penekanan milikku)

Dengan kata lain, mastertidak akan pernah di depan produksi. Demikian pula, masterakan selalu berada dalam keadaan stabil dan dapat dilepas (selain dari bug yang belum ditemukan), karena semuanya ditinjau, diuji, dan diluncurkan ke produksi sebelum digabungkan master.

— 8bree
sumber

Bagus! Ini sangat masuk akal secara intuitif - masterselalu posisi rollback Anda jika cabang fitur yang Anda dorong ke dalam produksi gagal. Jika tidak, itu akan bergabung masterdan menjadi fallback baru. Saya suka itu.

— Bill Horvath

1

Masalah yang saya lihat adalah bahwa Git / Hub flow deploy / merge mengasumsikan satu fitur sedang dikembangkan / diuji / digabung / disebarkan pada suatu waktu - dan seringkali dalam pengalaman saya hal ini tidak terjadi. Jika kami menggabungkan fitur pada satu waktu, ada peluang lebih besar untuk masalah regresi - hanya ditemukan setelah fitur tersebut digabungkan untuk dikuasai dan kemungkinan dalam produksi.

Perlu ada cara untuk menguji beberapa fitur, menggabungkan beberapa fitur dan menggunakan yang sama. Saya telah menggunakan 'cabang bundel' (cabang yang dibuat dari master dengan cabang fitur siap pakai digabung ke dalamnya) yang akan digunakan untuk qa / uat. Koreksi selama uat terjadi hanya pada cabang fitur, dan yang digabung kembali ke cabang bundel. Setelah subbagian dari cabang bundel disetujui, hanya fitur-fitur yang disetujui dalam bundel yang dapat diminta untuk dikuasai tarikan - dan siklusnya berkelanjutan.

Saya menggunakan ini dengan Gitflow, tetapi merenungkan untuk menggunakannya untuk aliran GitHub. Fitur QA / UAT banyak pada masalah waktu tampaknya penting. Masalah lain dengan aliran GitHub adalah mengasumsikan semua pengembang sr, dan itu tidak selalu terjadi.

Saya lebih suka menggunakan aliran GitHub karena kesederhanaannya. Dengan fitur seperti bundel, saya pikir ini akan lebih siap. Mungkin bundel ini mirip dengan rilis; Namun, saya masih memikirkan ini juga.

Masalah lainnya adalah proses permintaan tarik terjadi di akhir sebelum bergabung menjadi master; namun, terkadang Anda ingin mengkodekan ulasan sebelum pengujian qa bisnis - karenanya jauh sebelum penggabungan

— David Latty
sumber