2.6 Git Grundlagen - Taggen

Die Auflistung der vorhandenen Tags in Git ist unkompliziert. Gib einfach git tag (mit optionalem -l oder --list) ein:

Dieser Befehl listet die Tags in alphabetischer Reihenfolge auf. Die Reihenfolge, in der sie angezeigt werden, hat keine wirkliche Bedeutung.

Du kannst auch nach Tags suchen, die einer bestimmten Zeichenfolge entsprechen. Das Git-Source-Repo zum Beispiel enthält mehr als 500 Tags. Wenn du nur daran interessiert bist, dir die 1.8.5-Serie anzusehen, kannst du Folgendes ausführen:

Git unterstützt zwei Arten von Tags: lightweight (d.h. nicht-annotiert) und annotated.

Ein nicht-annotiertes Tag ist sehr ähnlich eines Branches, der sich nicht ändert – es ist nur ein Zeiger auf einen bestimmten Commit.

Annotierte Tags werden dagegen als vollständige Objekte in der Git-Datenbank gespeichert. Sie werden mit einer Prüfsumme versehen, enthalten den Tagger-Namen, die E-Mail-Adresse und das Datum, haben eine Tagging-Nachricht und können mit GNU Privacy Guard (GPG) signiert und überprüft werden. Es wird allgemein empfohlen annotierte Tags zu erstellen, damit all diese Informationen gespeichert werden; aber wenn du ein temporäres Tag wünschst oder aus irgendwelchen Gründen die anderen Informationen nicht speichern willst, sind auch nicht-annotierte Tags möglich.

Das Erstellen eines annotierten Tags in Git ist einfach. Der einfachste Weg ist die Eingabe von -a, beim Ausführen des tag Befehls:

Ein -m spezifiziert eine Tagging-Nachricht, die mit dem Tag gespeichert wird. Wenn du keine Nachricht für ein annotierten Tag angibst, startet Git deinen Editor, damit du eine Nachricht eingeben kannst.

Du kannst die Tag-Daten zusammen mit dem getaggten Commit sehen, indem du den Befehl git show verwendest:

Es werden die Tagger-Informationen, das Datum an dem der Commit getaggt wurde, und die Annotationsnachricht angezeigt, gefolgt von den Commit-Informationen.

Eine weitere Möglichkeit, Commits zu markieren, ist ein leichtgewichtiger, nicht-annotierter Tag. Das ist im Grunde genommen die in einer Datei gespeicherte Commit-Prüfsumme – es werden keine weiteren Informationen gespeichert. Um einen leichtgewichtigen Tag zu erstellen, gib keine der Optionen -a, -s oder -m an, sondern nur einen Tag-Namen:

Wenn du diesmal git show auf dem Tag ausführst, siehst du keine zusätzlichen Tag-Informationen. Der Befehl zeigt nur den Commit an:

Du kannst auch ältere Commits markieren. Angenommen, dein Commit-Verlauf sieht so aus:

Nehmen wir an, du hast vergessen, das Projekt mit v1.2 beim Commit von „Update rakefile“ zu taggen. Du kannst ihn nachträglich hinzufügen. Um diesen Commit zu markieren, gib am Ende des Befehls die Commit-Prüfsumme (oder einen Teil davon) an:

Du siehst, dass du den Commit getaggt hast:

Normalerweise überträgt der Befehl git push keine Tags an den Remote-Server. Du musst Tags explizit auf einen Server verschieben, nachdem du sie erstellt hast. Dieser Prozess funktioniert genauso wie das Teilen von Remote-Branches – Du musst dazu git push origin <tagname> ausführen.

Wenn du viele Tags hast, die du auf einmal pushen willst, kannst du auch die Option --tags mit dem Befehl git push verwenden. Dadurch werden alle deine Tags auf den Remote-Server übertragen, die sich noch nicht auf dem Server befinden.

Wenn jetzt jemand anderes aus deinem Repository klont oder pullt, erhält er auch alle deine Tags.

Um einen Tag aus dem lokalen Repository zu löschen, verwende git tag -d <tagname>. Wir könnten beispielsweise den leichtgewichtigen Tag wie folgt entfernen:

Beachte, dass dadurch der Tag nicht von Remote-Servern entfernt wird. Es gibt zwei gängige Varianten, um ein Tag von einem remote Server zu löschen.

Die erste Möglichkeit ist git push <remote> :refs/tags/<tagname>:

Zur Erklärung des obigen Befehls: Vor dem Doppelpunkt ist nichts und somit als Nullwert zu lesen. Darauf wird der Remote-Tag-Name gepusht, wodurch dieser gelöscht wird.

Der zweite, intuitivere Weg, ein Remote-Tag zu löschen, ist mit:

Wenn du die Dateiversion anzeigen möchtest, auf die ein bestimmter Tag zeigt, kannst du git checkout auf dieses Tag durchführen. Dies versetzt dein Repository in den Zustand „detached HEAD“ (dt. losgelöst), was einige negative Nebenwirkungen hat:

Wenn du im Zustand „detached HEAD“ Änderungen wornimmst und dann einen Commit erstellst, bleibt der Tag gleich, aber dein neuer Commit gehört zu keinem Branch und ist unzugänglich, außer mit dem genauen Commit-Hash. Wenn du also Änderungen vornehmen musst – z.B. wenn du einen Fehler in einer älteren Version behebst – wirst du normalerweise einen Branch erstellen:

Wenn du das tust und einen Commit erstellst, wird sich dein Branch version2 leicht von deinem Tag v2.0.0 unterscheiden, da er mit deinen neuen Änderungen fortschreitet, sei also vorsichtig.