Mengikuti git-flow, bagaimana seharusnya Anda menangani perbaikan terbaru dari rilis sebelumnya?

101

Jika Anda mencoba mengikuti model percabangan git-flow, yang didokumentasikan di sini dan dengan alat di sini , bagaimana Anda menangani situasi ini:

Anda telah membuat rilis 1.0 dan rilis 2.0. Maka Anda perlu membuat perbaikan terbaru untuk 1.0. Anda membuat cabang hotfix dari tag 1.0 dan menerapkan perbaikan di sana. Tapi lalu bagaimana?

Biasanya Anda akan menggabungkan ke master dan meletakkan tag rilis 1.1 di sana. Tetapi Anda tidak dapat menggabungkan 1.1 ke poin setelah 2.0 di master.

Saya rasa Anda bisa meletakkan tag rilis di cabang hotfix, tetapi itu akan membuat cabang permanen di samping master yang akan berisi tag rilis. Apakah itu cara yang benar?

— Klas Mellbourn
sumber

kemungkinan duplikat Git-flow dan master dengan beberapa cabang rilis paralel [meskipun pertanyaan lain lebih baru, ia memiliki jawaban yang lebih berguna jadi saya telah menandai pertanyaan ini sebagai duplikat]

— danio

74

Tampaknya ada konsep cabang "pendukung" di aliran git. Ini digunakan untuk menambahkan perbaikan terbaru ke rilis sebelumnya.

Untaian ini memiliki lebih banyak informasi , dengan contoh berikut:

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

... perbaiki, lalu:

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

atau menggunakan git flowperintah

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

... buat perubahan lalu:

git flow hotfix finish 6.0.1

— Klas Mellbourn
sumber

? Pertahankan cabang dukungan ini atau hapus setelah beberapa waktu

— Evan Hu

@EvanHu baik, pasti simpan mereka selama Anda memiliki cabang produksi di suatu tempat. Setelah itu masalah catatan sejarah. Anda mungkin ingin mengetahui bagaimana perbaikan terbaru diperbaiki jika terjadi berulang.

— Klas Mellbourn

Seseorang harus melakukan rilis pada hot fix, bukan? Bagaimana kita bisa melakukannya?

— Ravindranath Akila

33

Pertanyaan menarik! Alur yang Anda tautkan mengasumsikan master dapat melacak produksi. Itu hanya berfungsi jika versi produksi meningkat secara ketat. Itu biasanya benar untuk situs web yang hanya memiliki satu versi produksi.

Jika Anda harus mempertahankan beberapa versi produksi, satu cabang untuk melacak produksi tidak cukup. Solusinya adalah tidak menggunakan master untuk melacak produksi. Sebaliknya, gunakan cabang seperti release1, release2, dll

Dalam pendekatan ini, Anda bahkan mungkin tidak memerlukan cabang perbaikan terbaru. Anda bisa memperbaiki masalah di release1cabang. Jika perbaikan sudah cukup baik, buatlah release1.1tag di release1cabang.

— Andomar
sumber

Anda dapat mengubah git-flow untuk menyetel tag rilis di cabang rilis. Itu perubahan yang cukup besar. Itu akan merusak skrip saat ini. Juga, apa yang akan dikandung oleh master?

— Klas Mellbourn

3

The git-flowperkakas tidak cocok jika Anda harus mendukung beberapa versi produksi. Dalam alur kerja yang diusulkan dalam jawaban ini, master tidak digunakan sama sekali. Anda bisa menamai master cabang pengembangan, itu hanya sebuah nama.

— Andomar

GitFlow mendukung pelacakan lebih dari satu versi produksi: gitversion.readthedocs.io/en/latest/git-branching-strategies/…

— Andre L

7

git-flow mengasumsikan Anda hanya mendukung satu jalur rilis pada satu waktu, dengan mudah dilacak oleh master. Jika Anda mempertahankan lebih dari 1, maka Anda perlu memodifikasi proses git-flow untuk memiliki beberapa pelacak dari rilis terpisah yang Anda dukung (master-1, master-2). Anda dapat terus menggunakan master untuk melacak baris rilis terbaru, selain atau sebagai pengganti dari pelacak tertentu untuk baris rilis terbaru (master sebagai pengganti master-2).

Sayangnya, semua perkakas git-flow yang mungkin Anda gunakan mungkin perlu dimodifikasi, tetapi semoga Anda cukup paham dengan proses git-flow untuk menangani kasus khusus ini secara langsung dengan perintah git.

— Bert F
sumber

Jika Anda memodifikasi git flowproses maka itu akan menjadi sesuatu yang berbeda. Jika beberapa model harus diperbaiki (tidak hanya diperpanjang) maka itu sesukses yang dinyatakan oleh pembuatnya. Silakan lihat jawaban saya untuk topik yang kita diskusikan.

— Victor Yarema

0

git config --add gitflow.multi-hotfix true Perintah ini sepertinya berhasil untuk saya!

— Laila
sumber