Git-flow dan master dengan beberapa cabang rilis paralel


87

Kami mencoba untuk mengadopsi model percabangan Git yang berhasil diimplementasikan oleh git-flow. Sekarang, kami sedang mengerjakan setidaknya dua cabang rilis, satu untuk rilis stabil terbaru dan satu lagi untuk rilis berikutnya ("pratinjau"). Apa yang saya tidak mengerti adalah mengapa semua rilis tampaknya "dilinierisasi" ke master dan diberi tag di sana. Mengapa tidak menandai rilis di cabang rilis mereka? Mengapa tuannya sama sekali? Atau mengapa mengembangkan cabang dan tidak menggunakan master untuk itu?

Jawaban:


77

Dalam model git-flow, versi "rilis terbaru" Anda sebenarnya memetakan ke master, sementara "rilis pratinjau" Anda dipetakan ke releasecabang git-flow . Itu bercabang dari developdan akhirnya digabungkan menjadi mastersaat rilis sebenarnya terjadi. Kemudian ini akan menjadi "rilis terbaru" Anda dan biasanya Anda hanya akan memperbaiki bug untuk rilis tersebut, menggunakan hotfixcabang git-flow . Dengan cara ini, Anda masterselalu mewakili status paling stabil dari versi rilis terbaru Anda.

Jika Anda ingin memperbaiki bug untuk rilis lama atau melakukan pengembangan lain di sana, Anda akan bercabang dengan supportcabang dari komit yang sesuai master(Anda akan memiliki semua versi yang pernah dibuat di sana). supportcabang masih eksperimental ( menurut dokumen ) dan tidak didokumentasikan dengan baik. Tetapi seperti yang Anda lihat dari bantuan baris perintah:

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

cabang-cabang ini baru saja dimulai dan tidak dimaksudkan untuk digabungkan kembali ke masternor develop. Ini biasanya baik-baik saja, karena perbaikan pada rilis "kuno" atau fitur yang diminta oleh pelanggan untuk diimplementasikan dalam rilis "kuno" tidak dapat atau tidak boleh kembali master. Jika Anda masih berpikir, Anda ingin mengirim perbaikan ke jalur pengembangan utama Anda (diwakili oleh masterdan develop), cukup mulai a hotfix, pilih ceri perubahan Anda dan selesaikan hotfix.


17
Ini tidak berhubungan dengan pipeline yang lambat dari Test ke QA ke produksi. Mungkin ada dua (atau bahkan lebih, tapi katakan saja dua untuk saat ini) cabang rilis terbuka, masing-masing dalam tahap yang berbeda dari pipeline itu dan masing-masing diperlukan untuk memungkinkan perbaikan bug yang ditemukan dalam pengujian. The mengembangkan cabang maka akan di mana fitur sedang akumulasi untuk rilis yang cabang belum dibuat. Dalam situasi seperti itu, perbaikan pada rilis n-2 pada akhirnya akan digabungkan untuk dikembangkan, tetapi akan melewati rilis n-1, setidaknya mengikuti aliran git standar. Hal ini akan menyebabkan regresi pada n-1, akhirnya diperbaiki pada rilis n
Brendan

Mengapa rilis cabang tidak disimpan dan setelah rilis cabang baru dibuat, lebih lama berkembang menjadi cabang "dukungan"?
lkanab

1
Mengapa rilis cabang "bercabang" dari berkembang dan tidak hanya "bercabang" dari berkembang?
Sandra K

gitflow-avh tampak seperti garpu yang dipertahankan (bukan mati) dari gitflow asli. git flow supporttidak ditandai sebagai eksperimental.
Timo Verhoeven

9

Sepertinya sebagian besar model mental dengan terlalu banyak penekanan pada cabang. Saya setuju, Anda cukup menandai komitmen yang Anda lepaskan alih-alih menggabungkannya kembali menjadi master.

Tapi gambarnya cantik. Menggabungkan semuanya kembali ke master memberikan indikasi yang jelas tentang rilis dalam urutan sementara alih-alih tag versi bertebaran di seluruh grafik.

Saya pikir model ini tidak berfungsi untuk perbaikan bug di rilis lama. Itu mengacaukan pemesanan yang rapi.

  1. Katakanlah kita telah merilis Versi 1.0.1 dan yang lebih baru menambahkan fitur dan merilis 1.1.0.
  2. Kami menemukan bug di 1.0.1 dan ingin memperbaikinya di kedua versi
  3. Kita harus menambahkan 1.0.2 setelah 1.1.0 di master dan kemudian langsung atfer (atau sebelumnya) juga 1.1.1.

Untuk menjawab pertanyaan Anda: Saya pikir ini adalah seperangkat aturan yang membuat model mental sederhana dalam beberapa kasus. Tidak semua aturan masuk akal dari sudut pandang teknis, tetapi itu tidak membuatnya buruk. Model mental baik untuk mereka manusia.


1
supportBranch dirancang untuk memperbaiki bug di rilis lama, meskipun masih diberi label 'eksperimental'.
mstrap

2

Saya pribadi berpikir aliran git yang disebutkan terlalu rumit.

Jika Anda menggunakan GitHub, coba GitHub flow(seperti yang dijelaskan oleh Scott Chacon).

Ini sangat berguna untuk kolaborasi pada beberapa fitur, peninjauan kode, dan Anda dapat menggabungkannya dengan solusi Integrasi Berkelanjutan menggunakan Commit Status API.

UPDATE : Ada situs resmi baru dari The GitHub Flow ™

PEMBARUAN 2 : Ada Panduan GitHub resmi baru (dan disederhanakan) untuk The GitHub Flow ™: https://guides.github.com/introduction/flow/


10
Aliran GitHub hanya cocok untuk konteks non-rilis-sentris: Proses aliran-git dirancang sebagian besar di sekitar "rilis". Kami tidak benar-benar memiliki "rilis" karena kami menerapkan ke produksi setiap hari - seringkali beberapa kali sehari.
Remi Mélisson

10
Saya juga akan menambahkan bahwa git-flow tidak berfungsi dengan baik dalam konteks rilis-sentris yang memiliki rilis pemeliharaan. Misalnya, apa yang terjadi ketika rilis 1.2.1 terjadi setelah rilis 1.3.0? Ini mungkin tidak dapat digabungkan ke master, sebuah anomali dari kronologi pekerjaan.
Ken Williams

@KenWiams seperti yang dijelaskan dalam jawaban mstrap, untuk apa supportcabang itu. Tapi Anda benar, ini memang anomali bahwa rilis semacam itu tidak digabungkan kembali master, yang — menurut pemahaman saya — harus menampung semua rilis produksi.
beatngu13

2

Dalam kasus saya, saya memiliki dua versi dari perangkat lunak yang sama yang dasarnya sama tetapi setiap versi memiliki beberapa fitur yang berbeda.

Jadi saya membuat dua worktreeyang berarti, membuat dua cabang yang relevan dan berjalan lama di samping master.

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Lalu saya punya:

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

Ada satu repositori, tetapi saya memiliki 3 folder terpisah di samping satu sama lain untuk setiap cabang di atas. Dan buat perubahan umum pada master. lalu gabungkan dengan kedua versi lainnya.

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project

Perubahan spesifik dari setiap versi akan masuk ke folder yang sesuai juga, dan pekerjaan pada setiap proyek diisolasi dan IDE tidak akan membingungkan.

Semoga membantu.


2

Sangat setuju dengan @Mot.

Senang mendengar pertanyaan yang sama.

Tim kami juga diburu untuk model percabangan Universal yang lebih banyak daripada model yang Berhasil . Yaitu seperti @Mot disebutkan di atas - ide utamanya adalah untuk menghindari memperkenalkan repositori tambahan untuk mendukung rilis- * cabang dalam repo * .git terpisah seperti misalnya dilakukan oleh kernel.org untuk rilis stabil. Tapi kernel.org melakukannya demi meminimalkan ukuran yang diunduh.

Bagi saya sepertinya lebih bersih memiliki master sebagai mainline untuk berkembang .

Juga ada beberapa konflik dalam rilis- * model penggabungan untuk master dan penandaannya kemudian dengan ide untuk

menggunakan skrip Git hook untuk secara otomatis membangun dan meluncurkan perangkat lunak kami ke server produksi kami setiap kali ada komit pada master

karena penyelesaian (penggabungan dan penandaan) bukanlah transaksi atomik:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

dan jika git hook mulai membangun dengan dukungan pembuatan versi otomatis:

$git describe --tags --long >.ver

maka versi yang salah dapat dibuat untuk:

$ git merge --no-ff release-1.2

Saya tahu bahwa pembuatan versi di Successfull one memperkenalkan beberapa proses versi tambahan tetapi tidak otomatis.

Singkatnya - perbedaan utama yang kami perkenalkan pada model cabang untuk rilis- * penggabungan dan penandaan adalah: - memberi tag pada rilis pada Membuat cabangnya - menjaga cabang rilis untuk memungkinkan pemeliharaannya di masa mendatang


-2

Cabang master harus SELALU mewakili basis kode produksi Anda, oleh karena itu Anda selalu menggabungkan kode kembali ke master tepat setelah rilis produksi.

Pemberian tag digunakan untuk "mengingat" kode persis yang masuk ke rilis produksi sehingga Anda dapat kembali lagi nanti dan menganalisis kode jika terjadi kesalahan.

Dengan ini secara teoritis tidak masalah jika Anda memberi tag kode Anda di cabang rilis atau di cabang master setelah Anda menggabungkan kembali ke master. Saya pribadi lebih suka memberi tag kode pada cabang rilis karena ini persis kode yang masuk ke build / rilis (dengan asumsi ada yang salah dengan penggabungan).

Masalah dengan konsep cabang pengembangan adalah single threaded. Brendan dalam thread ini menyebutkan strategi yang dapat digunakan dengan melibatkan konsep pengembangan cabang.


4
Apa yang dimaksud dengan "basis kode produksi" jika Anda mengelola beberapa rilis, misalnya v1.0, v1.1, v1.5 secara paralel?
Thomas S.

Basis Kode Produksi adalah apa yang di produksi sekarang misalnya v1.0. Cabang-cabang tersebut membawa perubahan untuk rilis yang akan disebarkan ke produksi di masa depan, misalnya V1.0.1, v1.1 dan v2.0. Setelah rilis "masa depan" diterapkan ke produksi, rilis tersebut digabungkan kembali ke master, sehingga master mencerminkan apa yang ada dalam produksi. Itu juga digabungkan ke depan (misalnya v1.0.1 ke 1.1 dan v2.0) sehingga perubahan v1.0.1 tidak hilang ketika v1.1 dirilis ke produksi.
Bernie Lenz

4
Saya berbicara tentang mempertahankan beberapa versi rilis, bukan tentang versi mendatang.
Thomas S.

4
Anda sepertinya tidak mengerti saya. Tidak dapatkah Anda membayangkan bahwa di beberapa perusahaan beberapa versi rilis dipertahankan? Microsoft, misalnya, juga memelihara pembaruan untuk Windows 7, 8, 8.1 dan 10, jadi mengapa tidak perusahaan lain?
Thomas S.

1
Itu benar Thomas. Model ini diarahkan pada produk yang memiliki rilis produksi tunggal pada titik waktu tertentu, seperti misalnya situs web. Saya juga menggunakan model ini untuk build seluler misalnya android dan iPhone di mana build diberi parameter untuk menghasilkan build Android atau iPhone (atau keduanya) menggunakan nomor versi yang sama. Saya penasaran untuk mengetahui masukan Anda tentang cara menyusun model build untuk produk yang memiliki beberapa versi langsung dalam produksi pada titik waktu tertentu mungkin dengan beberapa komponen yang dibagikan dan beberapa komponen berbeda. Harap beri tahu kami ...
Bernie Lenz
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.