Git-flow dan master dengan beberapa cabang rilis paralel

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?

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.

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.

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/

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.

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

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.