Warum sollte ich mich für leichte und annotierte Tags interessieren?

Lesezeit: 11 Minuten

Warum sollte ich mich fur leichte und annotierte Tags interessieren
Ben Blank

Ich bin letztes Jahr von Subversion auf Git als mein tägliches VCS umgestiegen und versuche immer noch, die Feinheiten von “Git-Denken” zu verstehen.

Was mich in letzter Zeit gestört hat, ist “leichte” vs. kommentierte vs. signierte Tags. Es scheint ziemlich allgemein anerkannt zu sein, dass annotierte Tags leichtgewichtigen Tags für alle realen Verwendungszwecke überlegen sind, aber die Erklärungen, die ich dafür gefunden habe, warum das der Fall ist, scheinen sich immer entweder auf „weil Best Practices“ oder „weil sie anders sind“. Leider sind das sehr unbefriedigende Argumente ohne es zu wissen warum es ist Best Practices oder wie diese Unterschiede sind relevant zu meiner Git-Nutzung.

Als ich zum ersten Mal zu Git wechselte, schienen Lightweight-Tags das Beste seit geschnittenem Brot zu sein; Ich könnte 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 sicherlich nicht glauben, dass die Git-Experten der Welt willkürlich kommentierte Tags bevorzugen! Also, was soll der ganze Trubel?

(Bonuspunkte: Warum sollte ich jemals einen Tag unterschreiben müssen?)

BEARBEITEN

Ich bin erfolgreich davon überzeugt worden, dass kommentierte Tags eine gute Sache sind – es ist wichtig zu wissen, wer wann markiert hat! Als Follow-up, irgendwelche Ratschläge zu guten Tag-Anmerkungen? Beide git tag -am "tagging 1.0" 1.0 und der Versuch, das Commit-Protokoll seit dem vorherigen Tag zusammenzufassen, fühlt sich an, als würde man Strategien verlieren.

  • Haben Sie eine gute Antwort für Ihr Follow-up gefunden? Etwas wie? git log --pretty=oneline master..HEAD | git tag -a -F - $BRANCH.$BUILD_NUMBER

    – dalore

    16. Mai 2016 um 12:20 Uhr

  • Das Zusammenfassen des Commit-Logs seit dem vorherigen Tag scheint mir eine ausgezeichnete Strategie für Tag-Nachrichten zu sein.

    – robby

    19. August 2016 um 0:36 Uhr

  • FYI (1.) Um LIGHTWEIGHT-Tags nach Datum aufzulisten, gehen Sie hier. (2.) Um KOMMENTIERTE Tags nach Datum aufzulisten, gehen Sie hier.

    – Trevor Boyd Smith

    21. Februar 2018 um 13:09 Uhr

Warum sollte ich mich fur leichte und annotierte Tags interessieren
Cascabel

Das große Plus eines annotierten Tags ist, dass Sie wissen, wer es erstellt hat. Genau wie bei Commits ist es manchmal schön zu wissen, wer es getan hat. Wenn Sie ein Entwickler sind und sehen, dass v1.7.4 markiert (als bereit erklärt) wurde und Sie sich nicht sicher sind, mit wem sprechen Sie? Die Person, deren Name im annotierten Tag steht! (Wenn Sie in einer misstrauischen Welt leben, hält dies die Leute auch davon ab, Dinge zu markieren, die sie nicht 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 ist herrausgebracht.

Auch die anderen Metadaten können hilfreich sein – manchmal ist es schön zu wissen, wann diese Version veröffentlicht wurde, nicht nur, wann die endgültige Übergabe erfolgte. Und manchmal kann die Nachricht sogar nützlich sein. Vielleicht hilft es, den Zweck dieses bestimmten Tags zu erklären. Vielleicht enthält das Tag für einen Release Candidate so etwas wie eine Status-/To-do-Liste.

Das Signieren von Tags ist so ziemlich 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 möchten, bevor Sie diese Software auf Ihrem Computer installieren, möchten Sie es vielleicht.

Bearbeiten:

Was Sie in eine Tag-Anmerkung schreiben sollten, Sie haben Recht – es gibt nicht immer viel Nützliches zu sagen. Bei einem Versionsnummer-Tag wird implizit davon ausgegangen, dass es diese Version markiert, und wenn Sie mit Ihren Änderungsprotokollen an anderer Stelle zufrieden sind, müssen Sie dort keins einfügen. In diesem Fall sind Tagger und Datum wirklich die wichtigsten. Das einzige andere, was mir einfällt, ist eine Art Gütesiegel einer Testsuite. Schauen Sie sich die Tags von git.git an: Sie sagen alle einfach so 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 Nachricht jedoch viel wichtiger werden. Ich könnte mir vorstellen, eine bestimmte Spezialversion für einen einzelnen Benutzer/Client, einen wichtigen Nicht-Versionsmeilenstein oder (wie oben erwähnt) einen Release Candidate mit zusätzlichen Informationen zu markieren. Die Nachricht ist dann viel nützlicher.

  • Nur zum Vergleich mit SVN, da das OP von diesem System kommt: Die annotierten Tag-Metadaten entsprechen der tatsächlichen SVN-Änderung, die den Tag-Zweig macht, der in SVN einen eigenen Autor und eine eigene Nachricht hat. Und möglicherweise separate Einschränkungen, wer ein Tag erstellen darf, und nicht, wer Änderungen einchecken kann – eine Unterscheidung, die irrelevant ist, wenn Sie das System nur für Ihre eigenen Sachen verwenden.

    – araqnid

    11. Februar 2011 um 17:02 Uhr

  • Ah ha! Es hört sich so an, als ob mein Verständnis hier durch die Tatsache behindert wurde, dass alle meine bisherigen Git-Projekte solo waren. Ich musste nie wissen, wer für etwas verantwortlich ist (ich bin es immer!), also war mir nicht aufgefallen, dass Lightweight-Tags den Tagger nicht verfolgen.

    – Ben Blank

    11. Februar 2011 um 18:39 Uhr

  • git help log fasst dies nun wie folgt zusammen: “Annotierte Tags sind für die Freigabe gedacht, während Lightweight-Tags für private oder temporäre Objektkennzeichnungen gedacht sind.”

    – Jon Gjengset

    29. Mai 2014 um 15:19 Uhr

  • @javabrett Während dies ein guter Teil einer Antwort auf “Was sind die Unterschiede zwischen annotierten und leichten Tags” ist, war die Frage hier speziell, warum Leute zusätzliche Informationen speichern und daher annotierte Tags verwenden möchten. (Und ich glaube nicht, dass ich ernsthaft sagen könnte, dass “es einen Blob erstellt” ein Nachteil ist – Sie tun, was Sie tun müssen, um die Informationen zu speichern, die Sie speichern möchten, und wenn es sich um wichtige Informationen handelt, ist ein Blob erforderlich. )

    – Kaskabel

    15. September 2016 um 2:13 Uhr

  • @Chris ja, wie die Antwort sagt: “Das große Plus eines kommentierten Tags ist, dass Sie wissen, wer es erstellt hat.” Sie können immer selbst ausprobieren, um herauszufinden: git tag -a -m 'my message' my-tag; git show my-tag

    – Kaskabel

    9. August 2017 um 16:17 Uhr

Warum sollte ich mich fur leichte und annotierte Tags interessieren
Koraktor

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

  • Annotierte Tags sind Tags, die für andere Entwickler veröffentlicht werden sollen, höchstwahrscheinlich neue Versionen (die auch signiert werden sollten). Nicht nur, um zu sehen, wer wann getaggt hat, sondern auch warum (normalerweise ein Änderungsprotokoll).
  • Lightweight sind eher für den privaten Gebrauch geeignet, d.h. spezielle Commits zu taggen, um sie wiederzufinden. Sei es, um sie zu überprüfen, sie auszuprobieren, um etwas zu testen oder was auch immer.

  • Dies wird auch auf man git-tag erwähnt: „Annotated tags are mean for release while Lightweight tags are mean for private or temporal object label.“: stackoverflow.com/a/35059291/895245

    – Ciro Santilli 新疆再教育营六四事件法轮功郝海东

    12. Januar 2018 um 13:03 Uhr

1646312292 818 Warum sollte ich mich fur leichte und annotierte Tags interessieren
Phil Müller

Standardmäßig betrachtet Git nur annotierte Tags als Grundlage für Befehle wie git describe. Stellen Sie sich annotierte Tags als Wegweiser vor, die für Sie und andere eine dauerhafte Bedeutung haben, während leichte Tags eher wie Lesezeichen sind, die Sie später finden können. Daher lohnt es sich, annotierte Tags als Referenz zu verwenden, während einfache Tags dies nicht sein sollten.

Das Unterschreiben eines Tags ist eine Zusicherung der Identität des Unterzeichners. Damit können Benutzer beispielsweise überprüfen, ob der Linux-Kernel-Code, den sie aufgeschnappt haben, derselbe Code ist, den Linus Torvalds tatsächlich veröffentlicht hat. Die Signatur kann auch eine Behauptung sein, dass der Unterzeichner für die Qualität und Integrität der Software bei diesem Commit bürgt.

  • git push --follow-tags ist ein weiterer Befehl, der beide unterschiedlich behandelt: stackoverflow.com/a/26438076/895245

    – Ciro Santilli 新疆再教育营六四事件法轮功郝海东

    6. Juli 2015 um 20:25 Uhr

  • Danke für den Hinweis bzgl git describe. Ich verwende es im Continuous-Integration-System und ein paar Mal war die Versionszeichenfolge nicht das, was ich erwartet hatte.

    – jjmontes

    10. Mai 2018 um 14:13 Uhr

1646312292 712 Warum sollte ich mich fur leichte und annotierte Tags interessieren
Ciro Santilli 新疆再教育营六四事件法轮功郝海东

Pushen Sie annotierte Tags, behalten Sie Lightweight Local bei

Bestimmte Git-Verhaltensweisen unterscheiden zwischen ihnen in einer Weise, dass diese Empfehlung nützlich ist, z. B.:

  • Annotierte Tags können eine Nachricht, einen Ersteller und ein Datum enthalten, die sich von dem Commit unterscheiden, auf das sie verweisen. Sie könnten sie also verwenden, um ein Release zu beschreiben, ohne ein Release-Commit zu machen.

    Lightweight-Tags haben diese zusätzlichen Informationen nicht und brauchen sie auch nicht, da Sie sie nur selbst zum Entwickeln verwenden werden.

  • git push –follow-tags pusht nur kommentierte Tags
  • git describe ohne Befehlszeilenoptionen sieht nur kommentierte Tags

man git-tag sagt:

Annotierte Tags sind für die Freigabe gedacht, während Lightweight-Tags für private oder temporäre Objektkennzeichnungen gedacht sind.

Interne Unterschiede

  • Sowohl leichte als auch annotierte Tags sind eine Datei unter .git/refs/tags das einen SHA-1 enthält

  • für Lightweight-Tags zeigt der SHA-1 direkt auf ein Commit:

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

    druckt das gleiche wie der 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 den SHA des annotierten Tag-Objekts:

    c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
    

    und dann können wir seinen Inhalt abrufen mit:

    git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
    

    Beispielausgabe:

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

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

    Eine detailliertere Analyse des Formats finden Sie unter: Was ist das Format eines Git-Tag-Objekts und wie berechnet man seinen SHA?

Boni

  • Feststellen, ob ein Tag annotiert ist:

    git cat-file -t tag
    

    Ausgänge commit für Leichtbau, tag für kommentiert.

  • Nur Lightweight-Tags auflisten: Wie kann ich alle Lightweight-Tags auflisten?

Das Signieren eines Tags ist eine einfache Möglichkeit, die Authentizität einer Veröffentlichung zu bestätigen.

Dies ist besonders nützlich in einem DVCS, 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 Version von einem Committer markiert und signiert wird, ist es möglich, ein falsches Release-Tag im Repository zu erkennen.

Ohne das Signieren würde ich auch nicht viel Sinn in annotierten Tags sehen.

  • Eigentlich könnte es dafür nützlich sein, eine Signatur zu haben, die nur den übergebenen Baum signiert, nicht seine gesamte Geschichte (es ist mir egal, ob jemand die Geschichte manipuliert hat, ich möchte nur sicher sein, dass ich den richtigen Code habe).

    – Paulo Ebermann

    11. Februar 2011 um 18:33 Uhr

1646312293 564 Warum sollte ich mich fur leichte und annotierte Tags interessieren
Übelkos

Ich habe die einzige gute Verwendung für Lightweight-Tags gefunden – das Erstellen einer Version auf GitHub im Nachhinein.

Wir haben unsere Software veröffentlicht und wir hatten die notwendigen Commits, wir haben uns nur nicht die Mühe gemacht, den Abschnitt „Release“ auf GitHub zu pflegen. Und als wir dem ein wenig Aufmerksamkeit geschenkt haben, haben wir festgestellt, dass wir auch einige frühere Veröffentlichungen mit korrekten alten Veröffentlichungsdaten für sie hinzufügen möchten.

Wenn wir einfach ein annotiertes Tag auf einem alten Commit erstellen würden, würde GitHub das Datum für die Veröffentlichung aus dem Tag-Objekt entnehmen. Als wir im Gegensatz dazu ein einfaches Tag für diesen alten Commit erstellt haben, begann die Veröffentlichung, das korrekte (alte) Datum anzuzeigen.
Quelle @ GitHub-Hilfe, ‘Über Veröffentlichungen’

Es scheint auch möglich zu sein, Ihr Wunschdatum für einen annotierten Commit anzugeben, aber es sieht für mich nicht so einfach aus:
https://www.kernel.org/pub/software/scm/git/docs/git-tag.html#_on_backdating_tags

  • Eigentlich könnte es dafür nützlich sein, eine Signatur zu haben, die nur den übergebenen Baum signiert, nicht seine gesamte Geschichte (es ist mir egal, ob jemand die Geschichte manipuliert hat, ich möchte nur sicher sein, dass ich den richtigen Code habe).

    – Paulo Ebermann

    11. Februar 2011 um 18:33 Uhr

1646312293 408 Warum sollte ich mich fur leichte und annotierte Tags interessieren
David

In meinem Büro fügen wir die Adresse der Release-Webseite in den Tag-Text ein. Die Release-Webseite beschreibt alle verschiedenen neuen Funktionen und Korrekturen seit der letzten Version. Das Management wird nicht im Git-Repo suchen, um herauszufinden, welche Änderungen vorgenommen wurden, und es ist schön, eine kurze Liste dessen zu haben, was in dieser Version enthalten ist.

923610cookie-checkWarum sollte ich mich für leichte und annotierte Tags interessieren?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy