Hafif ve açıklamalı etiketlere neden önem vermeliyim?

Geçen yıl günlük VCS'm olarak Subversion'dan Git'e geçtim ve hala "Git-think" nun daha ince noktalarını kavramaya çalışıyorum.

Son zamanlarda beni rahatsız eden, açıklamalı ve imzalı etiketlere karşı "hafif" tir. Açıklamalı etiketlerin tüm gerçek kullanımlar için hafif etiketlerden üstün olduğu evrensel olarak kabul edilmiş görünüyor, ancak durumun neden böyle olduğunu bulduğum açıklamalar her zaman "en iyi uygulamalar" veya "farklı oldukları için" . Ne yazık ki, bunlar neden en iyi uygulamalar olduğunu veya bu farklılıkların Git kullanımımla nasıl alakalı olduğunu bilmeden çok tatmin edici olmayan argümanlar .

Git'e ilk geçiş yaptığımda, hafif etiketler dilimlenmiş ekmeklerden beri en iyi şey gibi görünüyordu; Sadece bir taahhüdü işaret edebilir ve "bu 1.0" diyebilirim. Bir etiketin bundan daha fazlasına nasıl ihtiyaç duyabileceğini kavramada sorun yaşıyorum, ancak kesinlikle dünyanın Git uzmanlarının açıklamalı etiketleri keyfi olarak tercih ettiğine inanamıyorum! Peki tüm hubbub ne hakkında?

(Bonus puan: Neden bir etiketi imzalamam gerekiyor?)

DÜZENLE

Açıklamalı etiketlerin İyi Bir Şey olduğuna ikna oldum - kimin ne zaman etiketlendiğini bilmek! Bir takip olarak, iyi etiket ek açıklamaları hakkında tavsiyeleriniz var mı? Her ikisi de git tag -am "tagging 1.0" 1.0ve bir önceki etiketin kaybedilen stratejiler olduğunu düşündüğünden beri işlem günlüğünü özetlemeye çalışmak.

Açıklamalı bir etiketin en büyük artısı, etiketi kimin oluşturduğunu bilmenizdir. Tıpkı taahhütlerde olduğu gibi, bazen bunu kimin yaptığını bilmek güzel. Bir geliştiriciyseniz ve v1.7.4'ün etiketlendiğini (hazır olduğunu beyan ettiyseniz) ve o kadar emin değilseniz, kiminle konuşuyorsunuz? Adı açıklamalı etikette bulunan kişi! (Eğer güvensiz bir dünyada yaşıyorsanız, bu aynı zamanda insanların yapmamaları gereken şeyleri etiketlemekten kaçınmasını da engeller.) Bir tüketici iseniz, bu isim bir otorite damgasıdır: bu Junio ​​Hamano, git'in bu versiyonunun işte olduğunu söyler yayınlandı.

Diğer meta veriler de yardımcı olabilir - bazen sadece son taahhüdün ne zaman yapıldığını değil, bu sürümün ne zaman yayınlandığını bilmek güzeldir. Bazen mesaj bile faydalı olabilir. Belki de o etiketin amacını açıklamaya yardımcı olur. Belki bir sürüm adayının etiketi biraz durum / yapılacaklar listesi içerebilir.

Etiketleri imzalamak hemen hemen başka bir şeyi imzalamaya benzer - paranoyak için bir güvenlik düzeyi daha sağlar. Birçoğumuz onu kullanmayacağız, ancak bu yazılımı bilgisayarınıza koymadan önce her şeyi gerçekten doğrulamak istiyorsanız, isteyebilirsiniz.

Düzenle:

Bir etiket ek açıklamasında ne yazacağınıza gelince, haklısınız - her zaman söyleyecek çok şey yok. Bir sürüm numarası etiketi için, bu sürümü işaretlediği anlaşılır bir şekilde anlaşılmıştır ve başka bir yerde değişiklik günlüklerinizden memnunsanız, oraya bir tane koymanıza gerek yoktur. Bu durumda, gerçekten en önemli etiketleyici ve tarih. Aklıma gelen tek şey bir test paketinden onay damgası. Git.git'in etiketlerine bir göz atın: hepsi sadece "Git 1.7.3 rc1" gibi bir şey söylüyor; tek önem verdiğimiz Junio ​​Hamano'nun adı.

Ancak, daha az açık bir şekilde adlandırılan etiketler için, mesaj çok daha önemli hale gelebilir. Tek bir kullanıcı / istemci için belirli bir özel amaçlı sürümü, bazı önemli sürüm dışı kilometre taşını veya (yukarıda belirtildiği gibi) ekstra bilgi içeren bir sürüm adayını etiketlemeyi düşünebilirim. Bu durumda mesaj çok daha kullanışlıdır.

Bu konuyla ilgili kişisel, biraz farklı bakış açım:

• Açıklamalı etiketler, diğer geliştiriciler, büyük olasılıkla yeni sürümler (imzalanması gereken) için yayınlanması gereken etiketlerdir. Sadece kimin etiketlendiğini ve ne zaman etiketlendiğini görmek için değil, aynı zamanda nedenini (genellikle bir değişiklik günlüğü) görmek de mümkündür.
• Hafiflik özel kullanım için daha uygundur, yani özel taahhütlerin etiketlenmesi onları tekrar bulabilmek anlamına gelir. Onları gözden geçirmek, bir şeyleri test etmek için kontrol edin.

Git, varsayılan olarak yalnızca açıklamalı etiketlere, gibi komutlar için taban çizgisi olarak bakar git describe. Açıklamalı etiketleri, kendinize ve başkalarına kalıcı bir anlam taşıyan işaret tabelaları olarak düşünürken, hafif etiketler daha sonra kendinizin bulması için yer işaretlerine benzer. Bu nedenle, açıklamalı etiketler referans olarak kullanılmaya değer, ancak hafif etiketler olmamalıdır.

Bir etiketi imzalamak, imzalayanın kimliğinin bir güvencesidir. Kullanıcıların, örneğin, aldıkları Linux çekirdek kodunun Linus Torvalds'ın gerçekte yayınladığı kodla aynı olduğunu doğrulamasını sağlar. İmza ayrıca, imzalayanın yazılımın kalitesini ve bütünlüğünü bu taahhütte kefil ettiğini iddia edebilir.

Bir etiketi imzalamak, bir sürümün orijinalliğini kanıtlamanın kolay bir yoludur.

Bu, özellikle DVCS'de kullanışlıdır, çünkü herkes havuzu klonlayabilir ve geçmişi değiştirebilir (örn. Git-filter-branch aracılığıyla). Bir etiket imzalanırsa, imza git-filtre-şube işleminden sağ çıkmaz, bu nedenle her sürümün bir anahtar tarafından etiketlenip imzalandığına dair bir politikanız varsa, depodaki sahte bir serbest bırakma etiketini tespit etmek mümkündür.

İmzalama olmasaydı, açıklamalı etiketlerde de fazla bir nokta görmezdim.

Açıklamalı etiketleri itin, hafifliği yerel tutun

Bazı Git davranışları, bu öneriyi yararlı olacak şekilde aralarında ayrım yapar, örneğin:

• ek açıklamalı etiketler işaret ettikleri taahhütten farklı bir mesaj, içerik oluşturucu ve tarih içerebilir. Böylece bunları, bir yayın taahhüdü vermeden bir yayın tanımlamak için kullanabilirsiniz.

  Hafif etiketlerde fazladan bilgi yoktur ve buna gerek yoktur, çünkü yalnızca geliştirmek için kendiniz kullanacaksınız.

• git push --follow-tags yalnızca ek açıklama eklenmiş etiketleri iter
• git describe komut satırı seçenekleri olmadan yalnızca ek açıklama eklenmiş etiketleri görür

man git-tag diyor:

Açıklamalı etiketler serbest bırakılırken, hafif etiketler özel veya geçici nesne etiketleri içindir.

İç farklar

• hem hafif hem de açıklamalı etiketler, .git/refs/tagsSHA-1 içeren bir dosyadır

• hafif etiketler için SHA-1 doğrudan bir taahhüde işaret eder:

  git tag light
  cat .git/refs/tags/light
  

  KAFA SHA-1 ile aynı yazdırır.

  Başka meta veri içeremediklerine şaşmamalı.

• açıklamalı etiketler nesne veritabanındaki bir etiket nesnesini gösterir.

  git tag -as -m msg annot
  cat .git/refs/tags/annot
  

  açıklamalı etiket nesnesinin SHA'sını içerir:

  c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
  

  ve sonra içeriğini şu şekilde alabiliriz:

  git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
  

  örnek çıktı:

  object 4284c41353e51a07e4ed4192ad2e9eaada9c059f
  type commit
  tag annot
  tagger Ciro Santilli <your@mail.com> 1411478848 +0200
  
  msg
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.11 (GNU/Linux)
  
  <YOUR PGP SIGNATURE>
  -----END PGP SIGNAT
  

  Ek meta verileri bu şekilde içerir. Çıktıdan görebildiğimiz gibi, meta veri alanları:

  • işaret ettiği nesne
  • işaret ettiği nesnenin türü. Evet, etiket nesneleri yalnızca taahhütleri değil, lekeler gibi başka herhangi bir nesneyi de işaret edebilir .
  • etiketin adı
  • etiketleyici kimliği ve zaman damgası
  • İleti. PGP imzasının mesaja nasıl eklendiğini not edin

  Biçimin daha ayrıntılı bir analizi şu adreste bulunur: Git etiketi nesnesinin biçimi nedir ve SHA'sı nasıl hesaplanır?

Bonuslar

• Bir etiketin açıklanıp açıklanmadığını belirleyin:

  git cat-file -t tag
  

  Ek açıklamalı commitiçin hafif çıktılar tag.

• Yalnızca hafif etiketleri listele: Tüm hafif etiketleri nasıl listeleyebilirim?

Hafif etiketler için iyi bir kullanım buldum - GitHub'da geriye dönük olarak bir sürüm oluşturdum.

Yazılımımızı yayınladık ve gerekli taahhütleri aldık, GitHub'daki 'Release' bölümünü korumak için uğraşmadık. Ve buna biraz dikkat ettiğimizde, daha önce yayınlanmış bazı sürümleri de eklemek isteyeceğimizi fark ettik, bunlar için eski sürüm tarihleri ​​doğru.

Eski bir taahhütte yalnızca ek açıklama eklenmiş bir etiket oluşturursak GitHub, etiket nesnesinden yayınlanma tarihini alır. Bunun aksine, bu eski işlem için hafif bir etiket oluşturduğumuzda, sürüm doğru (eski) tarihi göstermeye başladı. Source @ GitHub yardım, 'Sürümler hakkında'

Ek açıklamalı bir taahhüt için istediğiniz tarihi belirtmeniz de mümkün görünüyor, ancak benim için o kadar basit görünmüyor: https://www.kernel.org/pub/software/scm/git/docs/git-tag. html # _on_backdating_tags

Ofisime, yayın web sayfası adresini etiket gövdesine koyacağız. Sürüm web sayfası, son sürümden bu yana tüm farklı yeni özellikleri ve düzeltmeleri detaylandırıyor. Yönetim, hangi değişikliklerin gerçekleştiğini öğrenmek için git repo'suna bakmayacak ve bu sürümde neler olduğu konusunda özlü bir listeye sahip olmak güzel.

Ek açıklama eklenmiş etiketler, yazar adı, sürüm notları, etiket mesajı ve tarih gibi ek meta verileri Git veritabanında tam nesneler olarak depolar. Tüm bu veriler projenizin herkese açık bir şekilde yayınlanması için önemlidir.

git etiketi -a v1.0.0

Hafif etiketler git deponuza bir etiket eklemenin en basit yoludur, çünkü sadece söz ettikleri taahhüdün karmasını saklarlar. Bir taahhüt için "yer imleri" gibi davranabilirler, bu nedenle, özel kullanım için harikadırlar.

git etiketi v1.0.0

Eski etiketleri sıralayabilir, listeleyebilir, silebilir, gösterebilir ve düzenleyebilirsiniz. Tüm bu işlevler, kodunuzun belirli sürümlerini belirlemenize yardımcı olacaktır. Etiketlerin neler yapabileceği hakkında daha iyi bir fikir edinmenize yardımcı olabilecek bu makaleyi buldum .

Benim için önemli fark, hafif etiketin zaman damgası olmamasıdır. Birkaç hafif etiket eklediğinizi varsayalım:

git tag v1
git tag v2
git tag v3

ve sonra belki daha sonra en son eklenen hafif etiketi almak istersiniz. Bunu yapmanın bir yolu yok. Ne "git description" ne de "git tag" size kronolojik olarak en son hafif etiketi vermeyecektir. "git tag -l" tümünü döndürebilir veya lex sırasına göre sıralayabilir, ancak tarihe / saate göre sıralayamaz. "git description --tags" kesinlikle son eklenen etiketi olmayan "v1" i döndürür.

Diğer taraftan, açıklamalı etiketler eklerseniz:

git tag v1 -m v1
git tag v2 -m v1
git tag v3 -m v1

her etiketin zaman damgasını alabilirsiniz ve "git description" kesinlikle son eklenen etiket olan "v3" i döndürür.