Dalam git, apakah ide buruk untuk membuat tag dengan nama yang sama dengan cabang yang dihapus?


20

Saya punya proyek dengan model percabangan git yang kira-kira mengikuti git-flow nvie .

Cabang rilis kami diberi nama dalam format SemVer , misv1.5.2

Setelah cabang rilis diberi lampu hijau untuk produksi, kami menutup cabang, dengan menggabungkannya menjadi master, menerapkan tag, dan kemudian menghapus cabang.

Saat kami segera menghapus cabang rilis, kami telah menggunakan pengidentifikasi yang sama untuk menandai cabang, misalnya v1.5.2

Inilah perintah yang akan kami gunakan untuk menutup cabang rilis:

$ git checkout master
$ git merge v1.5.2
$ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc"
$ git branch -d v1.5.2
$ git branch -dr origin/v1.5.2
$ git push origin :v1.5.2
$ git push
$ git push --tags

Ini tampaknya berfungsi di sebagian besar kasus, namun hal itu menyebabkan masalah dalam skenario di mana instance lain dari git repo (misalnya mesin dev lain, atau lingkungan pementasan) memiliki checkout lokal dari cabang v1.5.2.

The git push origin :v1.5.2perintah akan menghapus cabang di remote, tetapi tidak menghapus versi lokal dari cabang (jika ada) di semua repo.

Ini mengarah ke referensi yang ambigu, ketika mencoba checkout v1.5.2di repo-repo itu:

$ git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.

Bisakah ini dihindari tanpa menggunakan sintaks yang berbeda untuk cabang, misalnya release-v1.5.2, atau v1.5.2-rc?

Atau apakah itu tidak dapat dihindari, dan oleh karena itu ide dasarnya buruk untuk membuat tag dengan nama yang sama dengan cabang yang dihapus?

Jawaban:


19

Jika Anda benar-benar ingin mempertahankan skema penamaan ini, Anda dapat:

Putuskan bahwa Anda tidak peduli dengan peringatan ini

Yaitu, jika Anda senang dengan fakta bahwa:

  • git checkout <ref>akan memeriksa refs/heads/<ref>lebih refs/tags/<ref>(lihat git-checkout )
  • perintah lain akan digunakan refs/tags/<ref>lebih refs/heads/<ref>(lihat gitrevisions )

Misalnya, dalam repositori tes ini, v1.5.2cabang menunjuk ke komit B, tetapi v1.5.2tag menunjuk ke komit A.

% git log --oneline --decorate
8060f6f (HEAD, v1.5.2, master) commit B
0e69483 (tag: v1.5.2) commit A

git checkout lebih suka nama cabang:

% git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.
Switched to branch 'v1.5.2'
% git log --decorate --oneline -1
8060f6f (HEAD, v1.5.2, master) commit B

tetapi git logakan menggunakan nama tag:

% git log --decorate --oneline -1 v1.5.2
warning: refname 'v1.5.2' is ambiguous.
0e69483 (tag: v1.5.2) commit A

Ini bisa membingungkan.

Latih orang untuk menghapus cabang lokal mereka ketika mereka melihat tag baru

Ini mungkin sulit / canggung tergantung pada ukuran organisasi Anda.

Tulis pembungkus di sekitar "tarik git" dan "ambil git"

Artinya, tulis pembungkus yang memeriksa apakah ada tag yang membayangi nama cabang, dan memperingatkan tentang (atau menghapus) cabang-cabang itu. Ini terdengar menyakitkan, dan bisa jadi tidak diinginkan jika cabang teduh saat ini diperiksa.

Sayangnya, sepertinya cara termudah untuk menyelesaikan masalah ini mungkin dengan mengubah cara Anda memberi nama cabang Anda. Tautan yang Anda poskan menggunakan skema penamaan yang berbeda untuk tag dan cabang: jika Anda sudah sebagian besar mengikuti metode itu, mengadopsi skema penamaannya mungkin merupakan solusi termudah.


Terima kasih atas tanggapannya. Sangat membantu. Peluru pertama Anda menyatakan bahwa git checkoutakan memeriksa tag di atas cabang ketika ada referensi yang ambisius, namun ini bukan perilaku yang saya lihat, ref: gist.github.com/tommarshall/9376724 . Apakah ini sesuatu yang berubah dalam versi git yang lebih modern? Apakah ada bendera yang bisa saya atur gitconfiguntuk mendapatkan perilaku ini?
tommarshall

Anda benar, saya salah total. Maaf! Saya telah memperbaiki jawaban saya dan menambahkan contoh.
benj

10

Anda dapat secara eksplisit menentukan apakah Anda ingin cabang atau tag dengan menggunakan nama lengkap:

 git checkout refs/heads/v1.5.2

atau

git checkout refs/tags/v1.5.2
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.