Warum sollte ich mich für leichtgewichtige oder kommentierte Tags interessieren?

Question

Ich bin letztes Jahr von Subversion auf Git als mein tägliches VCS umgestiegen und versuche immer noch, die Feinheiten des "Git-Denkens" zu begreifen.

Die Frage, die mich in letzter Zeit beschäftigt hat, ist die nach "leichtgewichtigen" bzw. kommentierten bzw. signierten Tags. Es scheint ziemlich allgemein akzeptiert zu sein, dass kommentierte Tags den leichtgewichtigen Tags für alle realen Anwendungen überlegen sind, aber die Erklärungen, die ich gefunden habe, warum das der Fall ist, scheinen immer darauf hinauszulaufen, entweder "weil beste Praktiken" o "weil sie anders sind" . Leider sind das sehr unbefriedigende Argumente, ohne zu wissen warum die besten Praktiken oder wie diese Unterschiede . zu meiner Git-Verwendung.

Als ich zum ersten Mal zu Git wechselte, schienen leichtgewichtige Tags das Beste seit der Erfindung des Brotes zu sein; ich konnte einfach auf einen Commit zeigen und sagen "das war 1.0". Ich habe Schwierigkeiten zu verstehen, wie ein Tag jemals mehr als das sein könnte, aber ich kann nicht glauben, dass die Git-Experten der Welt willkürlich kommentierte Tags bevorzugen! Worum geht es also bei dem ganzen Trubel?

(Bonuspunkte: Warum sollte ich jemals ein Schild unterschreiben müssen?)

EDIT

Ich habe erfolgreich überzeugt dass kommentierte Tags eine gute Sache sind - zu wissen, wer wann getaggt hat, ist wichtig! Haben Sie einen Tipp für gute Tag-Anmerkungen? Beide git tag -am "tagging 1.0" 1.0 und der Versuch, das Commit-Protokoll seit dem letzten Tag zusammenzufassen, fühlen sich wie verlorene Strategien an.

Answer 1

Der große Vorteil eines kommentierten Tags ist, dass Sie wissen, wer ihn erstellt hat. Genau wie bei Übertragungen ist es manchmal schön zu wissen, wer es getan hat. Wenn Sie ein Entwickler sind und sehen, dass v1.7.4 mit einem Tag versehen wurde und Sie sich nicht sicher sind, mit wem sprechen Sie dann? Mit der Person, deren Name in dem kommentierten Tag steht! (Wenn Sie in einer misstrauischen Welt leben, hält dies auch Leute davon ab, Dinge zu markieren, die sie nicht markieren sollten.) Wenn Sie ein Verbraucher sind, ist dieser Name ein Stempel der Autorität: Das ist Junio Hamano, der sagt, dass diese Version von Git hiermit freigegeben ist.

Auch die anderen Metadaten können hilfreich sein - manchmal ist es gut zu wissen, wann die Version veröffentlicht wurde und nicht nur, wann der letzte Commit gemacht wurde. Und manchmal kann die Nachricht sogar nützlich sein. Vielleicht hilft sie, den Zweck dieses bestimmten Tags zu erklären. Vielleicht enthält das Tag für einen Release Candidate eine Art Status/To-Do-Liste.

Das Signieren von Tags ist so ähnlich wie das Signieren von allem anderen - es bietet eine weitere Sicherheitsebene für Paranoiker. Die meisten von uns werden es nie verwenden, aber wenn Sie wirklich alles überprüfen wollen, bevor Sie die Software auf Ihrem Computer installieren, ist es vielleicht sinnvoll.

Bearbeiten:

Sie haben Recht, dass es nicht immer viel Nützliches zu sagen gibt, was man in eine Tag-Anmerkung schreiben sollte. Bei einem Versionsnummer-Tag wird implizit davon ausgegangen, dass es diese Version kennzeichnet, und wenn Sie mit Ihren Änderungsprotokollen an anderer Stelle zufrieden sind, gibt es keinen Grund, dort eines zu setzen. In diesem Fall sind wirklich der Tagger und das Datum das Wichtigste. Die einzige andere Sache, die mir einfällt, ist eine Art Genehmigungsstempel von einer Test-Suite. Schauen Sie sich die Tags von git.git an: Sie sagen alle nur etwas wie "Git 1.7.3 rc1"; alles, was uns wirklich interessiert, ist Junio Hamanos Name darauf.

Bei weniger offensichtlich benannten Tags könnte die Botschaft jedoch sehr viel wichtiger werden. Ich könnte mir vorstellen, eine spezielle Version für einen einzelnen Benutzer/Kunden zu kennzeichnen, einen wichtigen Meilenstein, der keine Version ist, oder (wie oben erwähnt) einen Release Candidate mit zusätzlichen Informationen. Die Nachricht ist dann sehr viel nützlicher.

Answer 2

Meine persönliche, etwas andere Meinung zu diesem Thema:

• Kommentierte Tags sind die Tags, die für andere Entwickler veröffentlicht werden sollen, höchstwahrscheinlich neue Versionen (die ebenfalls signiert werden sollten). Nicht nur um zu sehen, wer es markiert hat und wann es markiert wurde, sondern auch warum (normalerweise ein Änderungsprotokoll).
• Leichtgewichte sind eher für den privaten Gebrauch geeignet, d.h. spezielle Commits werden mit Tags versehen, damit man sie wiederfinden kann. Sei es, um sie zu überprüfen, sie auszuchecken, um etwas zu testen oder was auch immer.

Answer 3

Standardmäßig betrachtet Git nur kommentierte Tags als Grundlage für Befehle wie git describe . Stellen Sie sich kommentierte Tags als Wegweiser vor, die für Sie selbst und andere eine dauerhafte Bedeutung haben, während leichte Tags eher wie Lesezeichen sind, die Sie später wiederfinden. Daher sind kommentierte Tags es wert, als Referenz verwendet zu werden, während leichtgewichtige Tags dies nicht sein sollten.

Die Unterzeichnung eines Etiketts ist eine Zusicherung der Identität des Unterzeichners. So können Benutzer beispielsweise überprüfen, ob der Linux-Kernel-Code, den sie erhalten haben, derselbe Code ist, den Linus Torvalds tatsächlich veröffentlicht hat. Die Signatur kann auch eine Zusicherung sein, dass der Unterzeichner für die Qualität und Integrität der Software bei dieser Übergabe bürgt.

Answer 4

Verschieben Sie kommentierte Tags, halten Sie leichtgewichtige Tags lokal

Bestimmte Verhaltensweisen von Git unterscheiden sich in einer Weise, die diese Empfehlung sinnvoll macht, z. B:

• kommentierte Tags können eine andere Nachricht, einen anderen Ersteller und ein anderes Datum enthalten als die Übertragung, auf die sie verweisen. Sie können sie also verwenden, um eine Version zu beschreiben, ohne einen Release-Commit zu machen.

  Leichtgewichtige Tags haben diese zusätzlichen Informationen nicht und brauchen sie auch nicht, da Sie sie nur für die eigene Entwicklung verwenden werden.

• git push --follow-tags wird nur kommentierte Tags verschieben

• git describe ohne Kommandozeilenoptionen sieht nur kommentierte Tags

man git-tag sagt:

Kommentierte Tags sind für die Veröffentlichung gedacht, während leichtgewichtige Tags für private oder temporäre Objektkennzeichnungen gedacht sind.

Interne Unterschiede

• sowohl leichtgewichtige als auch kommentierte Tags sind eine Datei unter .git/refs/tags die ein SHA-1 enthält

• für leichtgewichtige Tags verweist das SHA-1 direkt auf eine Übertragung:

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

  gibt dasselbe aus wie das SHA-1 des HEAD.

  Kein Wunder also, dass sie keine anderen Metadaten enthalten können.

• annotierte Tags verweisen auf ein Tag-Objekt in der Objektdatenbank.

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

  enthält das SHA des kommentierten Tag-Objekts:

  c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef

  und dann können wir seinen Inhalt mit bekommen:

  git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef

  Musterausgabe:

  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

  Und so enthält sie zusätzliche Metadaten. Wie wir in der Ausgabe sehen können, sind die Metadatenfelder:

  • das Objekt, auf das es zeigt
  • die Art des Objekts, auf das es zeigt. Ja, Tag-Objekte können auf jede andere Art von Objekt wie Blobs verweisen, nicht nur auf Commits .
  • der Name des Tags
  • Identität des Taggers und Zeitstempel
  • Nachricht. Beachten Sie, dass die PGP-Signatur einfach an die Nachricht angehängt wird

  Eine ausführlichere Analyse des Formats finden Sie unter: Was ist das Format eines Git-Tag-Objekts und wie berechnet man dessen SHA?

Boni

• Feststellen, ob ein Tag mit Anmerkungen versehen ist:

  git cat-file -t tag

  Ausgänge commit für Leichtgewichte, tag für annotiert.

• Nur leichtgewichtige Tags auflisten: Wie kann ich alle leichtgewichtigen Tags auflisten?

Answer 5

Die Unterzeichnung einer Kennzeichnung ist ein einfacher Weg, um die Authentizität einer Veröffentlichung zu bestätigen.

Dies ist besonders in einem DVCS nützlich, da jeder das Repository klonen und den Verlauf ändern kann (z. B. über git-filter-branch). Wenn ein Tag signiert ist, überlebt die Signatur eine git-filter-branch-Operation nicht. Wenn Sie also eine Richtlinie haben, dass jede Veröffentlichung von einem Committer getaggt und signiert wird, ist es möglich, ein gefälschtes Release-Tag im Repository zu entdecken.

Wenn es nicht um die Unterzeichnung ginge, würde ich auch nicht viel Sinn in kommentierten Tags sehen.