Git'te, silinen bir şubeyle aynı ada sahip bir etiket oluşturmak kötü bir fikir mi?


20

Kabaca nvie'nin git-akışını takip eden bir git dallanma modeline sahip bir projem var .

Sürüm şubelerimiz SemVer biçiminde adlandırılır , ör.v1.5.2

Bir serbest bırakma dalına üretim için yeşil ışık verildiğinde, dalı master ile birleştirerek, bir etiket uygulayarak ve sonra dalı silerek kapatırız.

Serbest bırakma dalını hemen sildiğimizden, dalı etiketlemek için aynı tanımlayıcıyı kullanıyoruz, ör. v1.5.2

Bir sürüm dalını kapatmak için kullanacağımız komutlar şunlardır:

$ 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

Bu, vakaların çoğunda işe yarıyor gibi görünse de, senaryoda başka bir git repo örneğinin (örn. Başka bir geliştirici makinesi veya hazırlama ortamı) v1.5.2 şubesinin yerel bir kasası olduğu soruna neden oluyor.

git push origin :v1.5.2Komut uzak şube siler, ancak tüm depolarındakii şubesinin sürümünü (varsa) silmez.

Bu v1.5.2, bu depolarda ödeme yapmayı denerken belirsiz bir referans sağlar :

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

Bu, dallar için farklı bir sözdizimi kullanmadan önlenebilir mi , örn. release-v1.5.2, Veya v1.5.2-rc?

Yoksa kaçınılmaz mıdır ve bu nedenle silinmiş bir dalla aynı ada sahip bir etiket oluşturmak temelde kötü bir fikir midir?

Yanıtlar:


19

Bu adlandırma düzenini kesinlikle korumak istiyorsanız şunları yapabilirsiniz:

Bu uyarıları önemsemediğinize karar verin

Yani, eğer şu durumdan memnunsanız:

  • git checkout <ref>kontrol edecek refs/heads/<ref>üzerinde refs/tags/<ref>(bkz git-ödeme )
  • Diğer komutlar kullanacağız refs/tags/<ref>üzerinde refs/heads/<ref>(bkz gitrevisions )

Örneğin, bu test veri havuzunda, v1.5.2şube B taahhüdünü, ancak v1.5.2etiket A taahhüdünü gösterir.

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

git checkout şube adlarını tercih eder:

% 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

ancak git logetiket adını kullanır:

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

Bu kafa karıştırıcı olabilir.

Yeni bir etiket gördüklerinde kullanıcıları yerel şubelerini silmeleri için eğitin

Kuruluşunuzun boyutuna bağlı olarak bu zor / garip olabilir.

"Git pull" ve "git fetch" etrafına bir paket yazın

Yani, şube adlarını gölgeleyen herhangi bir etiket olup olmadığını kontrol eden bir sarmalayıcı yazın ve bu dallar hakkında uyarı (veya silme). Bu acı verici geliyor ve gölgeli dalın şu anda kontrol edilmesi istenmeyen bir durum olabilir.

Ne yazık ki, bu sorunu çözmenin en kolay yolu, dallarınızı adlandırma şeklinizi değiştirmek olabilir. Gönderdiğiniz bağlantı, etiketler ve dallar için farklı adlandırma şemaları kullanır: zaten bu yöntemi zaten izliyorsanız, adlandırma şemasını benimsemek en kolay çözüm olabilir.


Yanıt için teşekkürler. Çok yararlı. İlk git checkoutmerminiz, önemli bir referans olduğunda etiketi şube üzerinde kontrol edeceğini belirtiyor , ancak bu gördüğüm davranış değil, ref: gist.github.com/tommarshall/9376724 . Bu git'in daha modern bir versiyonunda değişen bir şey mi? gitconfigBu davranışı elde etmek için ayarlayabileceğim bir bayrak var mı ?
tommarshall

Haklısın, bunu tamamen yanlış anladım. Afedersiniz! Cevabımı düzelttim ve bir örnek ekledim.
benj

10

Tam adı kullanarak bir dal mı yoksa etiket mi istediğinizi açıkça belirtebilirsiniz:

 git checkout refs/heads/v1.5.2

veya

git checkout refs/tags/v1.5.2
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.