Haruskah cabang rilis atau cabang master ditandai ketika gitflow digunakan?


16

Masalah ini menunjukkan bahwa:

Dari pemahaman saya menempatkan tag pada cabang rilis sebelum penggabungan (dan bukan pada cabang master) sebenarnya adalah hal yang benar untuk dilakukan sehingga dapat ditemukan oleh git menggambarkan - tag dari cabang pengembangan, juga. Lihat # 374

sementara posting lain :

Saya tidak sengaja menginstal versi 0.4.2-pre via homebrew hari ini dan bingung dengan cara penandaan bekerja di versi itu. Sebelumnya (versi 0.4.1) tag dibuat di cabang master, setelah cabang rilis digabungkan ke dalamnya. Sekarang tampaknya tag dibuat pada komit terakhir dari cabang rilis, yang sepertinya bukan ide yang baik untuk saya. Terutama jika Anda memiliki sistem build yang bergantung pada git tag dan membuat versi rilis jika HEAD adalah komit yang ditandai dan versi pengembangan jika salah satu dari komitmen berikut ini berkomitmen. Bisakah seseorang menjelaskan logika di balik perubahan ini kepada saya? Dan sehubungan dengan versi semantik, saya tidak akan menganggap ini sebagai versi singkat di tingkat patch!

Di tim kami, kami memiliki dan melakukan beberapa diskusi tentang ini. Beberapa menunjukkan bahwa tag perlu dibuat dari cabang master sementara yang lain lebih suka cabang rilis. Menurut gambar gitflow:

masukkan deskripsi gambar di sini

sepertinya tag ditempatkan pada master.


1
Saya tahu GitLab kesulitan dengan tag pada cabang ketika Anda memangkas cabang yang lebih tua, jadi akan lebih baik jika tag ada di master. Tidak yakin dengan alat git lainnya.
HorusKol

'The gitflow' menyiratkan bahwa alur kerja (buruk IMO) ini adalah alur kerja standar atau resmi git. Bukan itu.
Miles Rout

@MilesRout Apa alur kerja git favorit Anda?
030

untuk kasus saya, saya menggunakan nilai git tag untuk memberi nama versi aplikasi saat rilis, jadi saya membuatnya di cabang rilis.
Pikirkan Kode Dua Kali Sekali

Jawaban:


16

Pertama, Anda tidak dapat menandai cabang, Anda hanya dapat menandai komitmen.

Anda harus menandai komit yang benar-benar Anda lepaskan. Itulah gunanya melakukan penandaan versi. Jika Anda memiliki masalah dengan perangkat lunak di beberapa lingkungan (produksi atau lainnya), Anda dapat mengatakan dengan yakin bahwa masalah tersebut diperkenalkan oleh komit yang berasal dari rilis tersebut.

(Inilah sebabnya mengapa orang berbicara tentang 'bangunan yang dapat direproduksi': sehingga mereka dapat yakin bahwa proses rilis mereka tidak memperkenalkan bug baru yang tidak ada di lingkungan pratinjau / pementasan mereka, dan bahwa jika mereka memiliki bug dalam produksi sama biner berjalan di mesin mereka ketika mereka pergi untuk debug itu.)

Tidak ada gunanya menandai komit hijau kedua dari bawah (anak hijau komit ditandai 'Hanya perbaikan bug!') Sebagai 'v1.0' karena Anda tidak melepaskan komit itu untuk produksi. Anda merilis komit pada master. Anda bahkan dapat melihat bahwa aliran git telah menandainya sebagai 'Tag 1.0'.

Ingat, tag memiliki tujuan: untuk dengan mudah menemukan komitmen. Anda menandai komit sebagai 'v1.0' sehingga Anda dapat dengan mudah menemukan hal yang Anda lepaskan sebagai versi 1.0. Anda tidak memberi tag demi memiliki tag 'v1.0' di suatu tempat di pohon komit Anda secara samar-samar di dekat komit yang sebenarnya Anda lepaskan.

Jika Anda memiliki masalah menemukan tag dari cabang pengembangan Anda itu masalah yang sama sekali terpisah. Perbaiki alat yang Anda gunakan untuk menemukan tag. Atau lebih baik lagi: jangan gunakan git-flow. Kelihatannya bagus dalam diagram itu karena titik-titik berwarna yang indah dan garis-garis yang ditata dengan baik, tetapi dalam kenyataannya itu tampak seperti jaring berantakan garis-garis dan titik-titik berwarna.


3
You should tag the commit you actually release. Jadi jika misalnya 20 komit yang perlu dirilis berada di cabang rilis dan cabang ini digabung menjadi master, komit gabungan yang telah dibuat harus ditandai untuk mengetahui apa yang telah dirilis?
030

1
Ya, komit gabungan akan ditandai. Sebagai varian dari git-flow, saya juga telah melihat membuat / menandai "versi bump commit" secara langsung dibranch:master
rmharrison
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.