2.6 Git Grundlagen - Taggen

Die Auflistung der vorhandenen Tags in Git ist unkompliziert. Geben Sie 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.

Sie können auch nach Tags suchen, die einer bestimmten Zeichenfolge entsprechen. Das Git-Source-Repo zum Beispiel enthält mehr als 500 Tags. Wenn Sie nur daran interessiert sind, sich die 1.8.5-Serie anzusehen, können Sie 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, dass Sie annotierte Tags erstellen, damit Sie all diese Informationen erhalten können; aber wenn Sie ein temporäres Tag wünschen oder aus irgendwelchen Gründen die anderen Informationen nicht speichern wollen, sind auch nicht-annotierte Tags möglich.

Das Erstellen eines annotierten Tags in Git ist einfach. Der einfachste Weg ist die Eingabe von -a, wenn Sie den Befehl tag ausführen:

Ein -m spezifiziert eine Tagging-Nachricht, die mit dem Tag gespeichert wird. Wenn Sie keine Nachricht für ein annotiertes Tag angeben, startet Git Ihren Editor, damit Sie diese eingeben können.

Sie können die Tag-Daten zusammen mit dem getaggten Commit sehen, indem Sie den Befehl git show verwenden:

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, geben Sie keine der Optionen -a, -s oder -m an, sondern nur einen Tag-Namen:

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

Sie können auch ältere Commits markieren. Angenommen, Ihr Commit-Verlauf sieht so aus:

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

Sie sehen, dass Sie den Commit getaggt haben:

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

Wenn Sie viele Tags haben, die Sie auf einmal pushen wollen, können Sie auch die Option --tags mit dem Befehl git push verwenden. Dadurch werden alle Ihre Tags auf den Remote-Server übertragen, die sich noch nicht auf dem Server befinden.

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

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

Beachten Sie, dass dadurch das Tag nicht von Remote-Servern entfernt wird. Es gibt zwei gängige Varianten, um ein Tag von einem entfernten Server zu löschen.

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

Die Erklärung des obigen Befehls: als Nullwert zu lesen, bevor der Doppelpunkt auf den Remote-Tag-Name gepushed wird, wodurch dieser gelöscht wird.

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

Wenn Sie die Dateiversion anzeigen möchten, auf die ein bestimmter Tag zeigt, können Sie git checkout auf dieses Tag durchführen, obwohl dies Ihr Repository in den Zustand „detached HEAD“ (dt. losgelöst) versetzt, was einige negative Nebenwirkungen hat:

Wenn Sie im Zustand „losgelöster HEAD“ Änderungen vornehmen und dann einen Commit erstellen, bleibt der Tag gleich, aber Ihr neuer Commit gehört zu keinem Branch und ist unzugänglich, außer mit dem genauen Commit-Hash. Wenn Sie also Änderungen vornehmen müssen – z.B. wenn Sie einen Fehler in einer älteren Version beheben – sollten einen Branch erstellen:

Wenn Sie das tun und einen Commit erstellen, wird sich Ihr Branch version2 leicht von Ihrem Tag v2.0.0 unterscheiden, da er mit Ihren neuen Änderungen fortschreitet, seien Sie also vorsichtig.