Strategi cabang Git untuk tim pengembang kecil [ditutup]

186

Kami memiliki aplikasi web yang kami perbarui dan rilis hampir setiap hari. Kami menggunakan git sebagai VCS kami, dan strategi percabangan kami saat ini sangat sederhana dan rusak: kami memiliki cabang utama dan kami memeriksa perubahan yang kami 'sukai'. Ini bekerja, tetapi hanya sampai kami memeriksa perubahan yang melanggar.

Adakah yang punya strategi git branch favorit untuk tim kecil yang memenuhi persyaratan berikut:

Bekerja dengan baik untuk tim yang terdiri dari 2 hingga 3 pengembang
Ringan, dan tidak terlalu banyak proses
Memungkinkan pengembang untuk mengisolasi pekerjaan pada perbaikan bug dan fitur yang lebih besar dengan mudah
Memungkinkan kami untuk menjaga cabang stabil (untuk saat-saat 'oh sial' ketika kami harus membuat server produksi kami berfungsi)

Idealnya, saya ingin melihat proses Anda selangkah demi selangkah untuk seorang dev yang mengerjakan bug baru

git branch git-branch

— Bilal dan Olga
sumber

247

Anda mungkin mendapat manfaat dari alur kerja yang dijelaskan oleh Scott Chacon di Pro Git . Dalam alur kerja ini, Anda memiliki dua cabang yang selalu ada, kuasai , dan kembangkan .

master mewakili versi paling stabil dari proyek Anda dan Anda hanya akan menggunakan untuk produksi dari cabang ini.

mengembangkan berisi perubahan yang sedang berlangsung dan mungkin belum tentu siap untuk produksi.

Dari cabang pengembangan , Anda membuat cabang topik untuk mengerjakan fitur dan perbaikan individual. Setelah fitur / perbaikan Anda siap untuk digunakan, Anda menggabungkannya ke dalam pengembangan , di mana Anda dapat menguji bagaimana ia berinteraksi dengan cabang topik lain yang telah digabungkan oleh rekan kerja Anda. Setelah berkembang dalam kondisi stabil, gabungkan menjadi master . Itu harus selalu aman untuk digunakan untuk produksi dari master .

Scott menggambarkan cabang-cabang yang sudah berjalan lama ini sebagai "silo" kode, di mana kode di cabang yang kurang stabil pada akhirnya akan "lulus" ke yang dianggap lebih stabil setelah pengujian dan persetujuan umum oleh tim Anda.

Langkah demi langkah, alur kerja Anda di bawah model ini mungkin terlihat seperti ini:

Anda perlu memperbaiki bug.
Buat cabang yang disebut myfix yang didasarkan pada mengembangkan cabang.
Kerjakan bug di cabang topik ini sampai diperbaiki.
Gabungkan perbaikan saya ke dalam pengembangan . Jalankan tes.
Anda menemukan konflik memperbaiki Anda dengan cabang topik yang lain hisfix bahwa rekan kerja Anda bergabung ke dalam mengembangkan sementara Anda bekerja pada memperbaiki Anda.
Buat lebih banyak perubahan di cabang myfix untuk menangani konflik ini.
Gabungkan perbaikan saya ke dalam mengembangkan dan menjalankan tes lagi.
Semuanya bekerja dengan baik. Gabung berkembang menjadi master .
Menyebarkan ke produksi dari master kapan saja, karena Anda tahu itu stabil.

Untuk detail lebih lanjut tentang alur kerja ini, periksa bab Branching Workflows di Pro Git.

— Jimmy Cuadra
sumber

7

Scott Chacon juga memiliki artikel yang luar biasa di situsnya tentang bagaimana alur kerja Github dengan Git bekerja - scottchacon.com/2011/08/31/github-flow.html

— program247365

71

Saya pikir ini hebat, kecuali jika Anda membuat cabang perbaikan bug dari mengembangkan cabang, Anda memaksa Anda tidak dapat menggabungkannya menjadi master dan menyebarkannya tanpa juga menggabungkan segala sesuatu yang "baru" yang belum Anda rilis, yang mungkin akan sangat menyakitkan jika ada sesuatu di cabang itu yang perlu didokumentasikan / perubahan basis data atau hal lain yang sulit dilakukan. Saya pikir untuk "perbaikan terbaru" yang mendesak, Anda harus membuat cabang Anda dari master.

— Richard

5

Bagaimana jika kita mengembangkan 2 fitur terpisah, F1 dan F2, di mana F1 akan dirilis dalam seminggu tetapi F2 akan dirilis dalam 2 minggu, dengan asumsi bahwa pengembangan F1 dan F2 bersamaan? Ada saran tentang itu?

— Murat Derya Özen

4

Ini developadalah 'solusi' yang tidak perlu untuk masalah yang tidak dimiliki git. Sejauh yang saya tahu keberhasilan adalah karena artikel yang ditulis dengan baik jika salah arah dengan tidak ada komentar diperbolehkan. Ini artikel balasan barro.github.io/2016/02/...

— Tim Abell

5

Pada langkah 8, menggabungkan cabang pengembangan ke master terdengar seperti ide buruk mengingat bahwa beberapa kode dalam pengembangan mungkin tidak siap untuk diproduksi. Bukankah lebih baik kita menggabungkan cabang fitur menjadi master?

— Todd

45

Setelah masuk sebagai seorang pemula mencoba menemukan strategi lurus ke depan untuk mengajar ke devs lain yang tidak pernah menggunakan kontrol sumber. Ini adalah yang sesuai dengan http://nvie.com/posts/a-successful-git-branching-model/ Saya mencoba menggunakan alur kerja GIT standar yang ada di halaman manual tetapi sedikit membingungkan saya dan audiens saya sepenuhnya.

Selama 6 bulan terakhir saya hanya perlu memperbaiki konflik dua kali. Saya telah menambahkan langkah-langkah untuk selalu menguji setelah penggabungan dan untuk 'mengambil dan menggabungkan "atau' menarik -rebase" banyak (sekali di pagi dan sore hari) saat mengembangkan fitur. Kami juga menggunakan github.com sebagai tempat utama untuk menarik kode terbaru.

— Kopling
sumber

Itu tautan yang bagus! Alur kerja itu bekerja sangat baik untuk tim kecil kami yang selalu bekerja secara jarak jauh dan paralel pada beberapa versi rilis sekaligus. Sangat terdokumentasi dengan baik. Kopling terima kasih!

— keithxm23

Ah, jadi ini adalah tempat saya menemukan tautan itu :-) Saya melihat beberapa strategi Git sebelum menyiapkan proyek Git pertama saya (saya telah pindah dari SCCS ke CVS ke SVN selama bertahun-tahun dan sekarang saya ingin mencoba Git untuk proyek baru ) dan ini adalah yang paling masuk akal bagi saya. Saya mengenali pos Anda jadi saya cukup yakin di sinilah saya menemukannya. Terima kasih - ini bekerja dengan sangat baik!

— Boise

4

Saya mati sedikit di dalam setiap kali saya melihat seseorang mengambil posting blog itu. Inilah bantahan: barro.github.io/2016/02/...

— Tim Abell

Saya berbagi perasaan yang sama dengan Anda @TimAbell; Saya sangat merasa itu tidak benar ketika default master branchTIDAK digunakan yang paling sering menjadi pengembang dalam hal iniA successful Git branching model

— Nam G VU

35

(Buat komentar saya di atas itu jawaban sendiri, seperti yang seharusnya saya lakukan sebelumnya.)

Dari Scott Chacon of Github:

Bagaimana Kami Melakukannya Jadi, apa itu GitHub Flow?

Apa pun di cabang utama dapat digunakan

Untuk mengerjakan sesuatu yang baru, buat cabang off of master yang dinamai secara deskriptif (yaitu: new-oauth2-scopes)

Berkomitmen untuk cabang itu secara lokal dan secara teratur mendorong pekerjaan Anda ke cabang bernama yang sama di server

Saat Anda membutuhkan umpan balik atau bantuan, atau Anda pikir cabang siap untuk digabung, buka permintaan tarik

Setelah orang lain meninjau dan menandatangani fitur, Anda dapat menggabungkannya menjadi master

Setelah digabung dan didorong ke 'master', Anda bisa dan harus segera menyebar

Lihat seluruh artikel untuk lebih jelasnya: http://scottchacon.com/2011/08/31/github-flow.html

Perhatikan bahwa "tarik permintaan" adalah penemuan Github, dan itu adalah sesuatu yang dimasukkan ke situs web mereka, bukan Git itu sendiri: https://help.github.com/articles/using-pull-requests/

— program247365
sumber

4

Dengan tim yang lebih kecil dan pengembang yang kurang berpengalaman dengan git, kesederhanaan alur kerja ini menang. Satu-satunya hal yang kami lakukan secara berbeda adalah memiliki cabang 'pementasan' antara cabang fitur dan master yang bertindak sebagai situs QA langsung bagi non-dev untuk membolehkan fitur dalam lingkungan seperti produksi.

— Skuadron

@Squadron terdengar seperti Anda perlu menggunakan gurita untuk itu, yang memiliki gerbang bawaan ke ok / deny build memasuki lingkungan yang berbeda dan tidak mencemari kontrol sumber Anda dengan hal-hal seperti itu.

— Tim Abell

Membuat cabang fitur dari master dan kemudian menggabungkannya kembali untuk ditempatkan adalah OK, asalkan Anda memiliki tag sehingga ada titik rollback yang aman. Penyebaran tidak selalu berjalan sesuai rencana. Apakah Anda percaya pada "hanya maju ke depan" tidak masalah ketika Anda mengalami perdarahan uang.

— Razor

15

Gunakan mastercabang sebagai cabang pengembangan Anda dan buat cabang rilis untuk melakukan perbaikan bug.

Segala fitur baru akan berlangsung masterselama jendela pengembangan (baik dilakukan secara langsung atau sebagai cabang topik dengan permintaan-tarik, terserah Anda - tidak ditampilkan dalam grafik). Setelah semua fitur yang Anda rencanakan diimplementasikan, masukkan pembekuan fitur, dan lakukan pengujian. Saat Anda senang, tandai rilis ini mastersebagaiv1.0 .

Seiring waktu pengguna Anda akan menemukan bug di v1.0sehingga Anda akan ingin membuat cabang dari tag itu (mis. Beri nama setelah rilis 1.0) dan perbaiki bug tersebut di cabang. Ketika Anda sudah memiliki cukup bug yang diperbaiki yang menurut Anda menjamin rilis baru kemudian beri tag sebagai v1.0.1dan gabungkan kembali master.

Sementara itu jendela pengembangan baru dapat terjadi pada mastercabang yang pada akhirnya akan ditandai sebagaiv1.1 .

Bilas & ulangi.

Ini mengikuti logika penomoran Semantic Versioning .

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

— Leif Gruenwoldt
sumber

5

Jangan lupa untuk menggabungkan 1.0.1perubahan Anda kembali kemaster

— kwahn

Dan selalu ingat untuk rebase 1.1pada master setelah penggabungan 1.0.1- ini membantu meminimalkan kebingungan.

— Nam G VU

@NamGVU saya tidak akan merekomendasikan itu. 1.1adalah cabang rilis dan memiliki tag yang mewakili keadaan pasti satu atau lebih rilis. Rebasing cabang itu akan menyebabkan Anda kehilangan representasi itu. Saya sangat merekomendasikan pengaturan cabang rilis Anda untuk menolak dorongan paksa untuk mencegah hal ini.

— Leif Gruenwoldt

1

Tidak. Jangan gabungkan cabang rilis kembali menjadi master! Ini dapat memberi Anda segala macam sakit kepala yang tidak Anda butuhkan (menggabungkan barang-barang hanya rilis, menggabungkan konflik dengan rilis baru, melanggar build, sejarah non-linear, dll. Percayalah, saya telah melihat itu terjadi lebih dari sekali) . Sebaliknya, perlakukan rilis sebagai garpu. Lihat bitsnbites.eu/a-stable-mainline-branching-model-for-git

— m-bitsnbites

4

cherry-pick adalah pilihan yang lebih baik untuk mengambil perubahan rilis menjadi master

— BartoszKP

4

Dalam VCS, memiliki cabang "master" dengan cepat menunjukkan batasnya karena Anda tidak dapat mengejar semua upaya pengembangan pada saat yang sama di satu cabang.
Itu berarti Anda perlu tahu kapan harus bercabang .

Tetapi dalam sebuah DVCS (seperti dalam VCS "Terdesentralisasi"), Anda juga memiliki masalah publikasi , dengan cabang-cabang yang Anda simpan lokal untuk repositori Anda, dan cabang-cabang yang Anda dorong atau tarik dari situ.

Dalam konteks ini, mulailah dengan mengidentifikasi upaya pengembangan bersamaan Anda, dan putuskan proses publikasi (push / pull). Misalnya (dan ini bukan satu-satunya cara):

prod adalah cabang publik hanya-baca dengan kode dalam produksi. Semua orang bisa menariknya untuk:
- rebase pengembangannya saat ini di atasnya (untuk pengujian lokal, atau untuk mengintegrasikan repo dev lokal perbaikan terbaru yang dilakukan di prod repo pada cabang prod)
- cabang untuk melakukan fitur baru (dari kode stabil yang dikenal)
- cabang untuk memulai cabang rilis berikutnya (cabang yang akan diproduksi)
  tidak ada yang harus mendorong langsung ke prod (karenanya hanya baca)
rilis adalah cabang konsolidasi baca-tulis, di mana komit yang relevan dipilih untuk menjadi bagian dari rilis berikutnya.
Setiap orang dapat mendorong untuk melepaskan untuk memperbarui rilis berikutnya.
Setiap orang dapat menarik dari rilis tersebut untuk memperbarui proses konsolidasi lokalnya.
featureX adalah cabang baca-tulis pribadi (karena tidak perlu didorong ke pusat prod repo), dan dapat didorong / ditarik di antara repo dev. Ini merupakan upaya jangka menengah hingga panjang, berbeda dari pengembang harian
master mewakili dev saat ini, dan didorong / ditarik di antara repo dev.

Ada proses manajemen rilis lain, karena pertanyaan SO ini membuktikan .

— VONC
sumber

3

Bacalah Alur Kerja Git ReinH untuk tim Agile di sini: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

Ini bekerja sangat baik untuk tim kecil. Tujuannya di sini adalah untuk memastikan segala sesuatu yang berpotensi tidak stabil masuk ke cabang tertentu. Hanya bergabung kembali untuk dikuasai ketika Anda siap untuk semua orang yang bekerja di luar cabang fitur untuk menggunakannya.

Catatan: strategi ini hampir tidak spesifik git, tetapi git membuat penerapan strategi ini cukup mudah.

— ikan paus
sumber