Git-Tags

Git-Tags sind Referenzen, die auf bestimmte Commits in der Git-Historie verweisen. So können bestimmte Punkte in der Historie für eine bestimmte Version markiert werden, z.B. v3.9.16. Tags sind wie Git-Verzweigungen, die sich nicht ändern, also keine weitere Historie von Commits haben.

$ git tag TAGNAME

erstellt einen Tag, wobei TAGNAME eine semantische Bezeichnung für den aktuellen Zustand des Git-Repositories ist. Dabei unterscheidet Git zwei verschiedene Arten von Tags: annotierte und leichtgewichtige Tags. Sie unterscheiden sich in der Menge der zugehörigen Metadaten.

Annotierte Tags

Sie speichern nicht nur den TAGNAME, sondern auch zusätzliche Metadaten wie Namen und E-Mail-Adresse derjenigen Person, die den Tag erstellt hat sowie das Datum. Zudem haben annotierte Tags, ähnlich wie Commits Nachrichten. Ihr könnt solche Tags erstellen, z.B. mit git tag -a v3.9.16 -m 'Python 3.9.16'. Anshließend könnt ihr euch diese zusätzlichen Metadaten z.B. anzeigen lassen mit git show v3.9.16.

Leichtgewichtige Tags

Leichtgewichtige Tags können z.B. mit git tag v3.9.16 ohne die Optionen -a, -s oder -m erstellt werden. Sie erstellen eine Tag-Prüfsumme, die im .git/-Verzeichnis eures Repos gespeichert werden.

git tag

$ git tag

listet die Tags eures Repos auf, z.B.:

0.1.0
0.1.1
0.1.10
0.1.11
0.1.12
0.1.2
…

Tipp

Die Reiehnfolge der Tags entspricht jedoch nicht derjenigen, die wir eigentlich erwarten würden: Nach 0.1.1 erwarten wir 0.1.2 und nicht 0.1.10. Um dies zu erreichen, können wir Git folgendermaßen konfigurieren:

git config --global tag.sort version:refname
$ git tag -l 'REGEX'

listet nur Tags auf, die zu einem regulären Ausdruck passen.

$ git tag -a TAGNAME COMMIT-SHA

erstellt einen Tag für einen früheren Commit.

Die vorangegangenen Beispiele erstellen Tags für implizite Commits, die auf HEAD verweisen. Alternativ kann git tag auch die Referenz auf einen bestimmten Commit übergeben werden, die ihr mit Rückblick erhaltet.

Wenn ihr jedoch versucht, ein Tag mit dem gleichen Bezeichner wie ein bestehendes Tag zu erstellen, gibt Git eine Fehlermeldung aus, z.B. Schwerwiegend: Tag 'v3.9.16' existiert bereits. Wenn ihr versucht, einen älteren Commit mit einem bestehenden Tag zu markieren, gibt Git denselben Fehler aus.

Für den Fall, dass ihr einen bestehendes Tag aktualisieren müsst, könnt ihr die Option -f verwenden, z.B.:

$ git tag -af v3.9.16 595f9ccb0c059f2fb5bf13643bfc0cdd5b55a422 -m 'Python 3.9.16'
Tag 'v3.9.16' aktualisiert (war 4f5c5473ea)
$ git push origin TAGNAME

Das Teilen von Tags ist ähnlich wie der Push von Zweigen: standardmäßig werden mit git push keine Tags freigegeben, sondern sie müssen explizit an git push übergeben werden z.B.:

$ git tag -af v3.9.16 -m 'Python 3.9.16'
$ git push origin v3.9.16
Counting objects: 1, done.
Writing objects: 100% (1/1), 161 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:python/cpython.git
 * [new tag]         v3.9.16 -> v3.9.16

Um Tags an den Server zu übermitteln, könnt ihr die --tags-Option für den Befehl git push verwenden. Andere erhalten die Tags bei git clone, git pull oder git fetch des Repos.

Mit git push --follow-tags könnt ihr mit einem Commit auch gleichzeitig die zugehörigen annotierten Tags teilen.

Bemerkung

--follow-tags funktioniert nur für annotierte Tags, nicht für die leichtgewichtigen Tags.

Wenn ihr für alle zukünftigen Pushes --follow-tags verwenden wollt, könnt ihr dies konfigurieren mit

$ git config --global push.followTags true

Siehe auch

$ git checkout TAGNAME

wechselt in den Zustand des Repository mit diesem Tag und trennt HEAD ab. D.h., dass alle Änderungen, die nun vorgenommen werden, das Tag nicht aktualisieren, sondern in einem losgelösten Commit landen, der nicht Teil eines Zweiges sein kann und nur direkt über den SHA-Hash des Commits erreichbar sein wird. Daher wird meist ein neuer Zweig erstellt, wenn solche Änderungen vorgenommen werden sollen, z.B. mit git checkout -b v3.9.17 v3.9.16.

$ git tag -d TAGNAME

löscht einen Tag, z.B.:

$ git tag -d v3.9.16
$ git push origin --delete v3.9.16

Wenn Tags, die auf dem Server gelöscht wurden, auch bei euch lokal gelöscht werden sollen, könnt ihr git fetch --prune-tags verwenden. Alternativ könnt ihr auch die globale Konfiguration anpassen mit:

$ git config --global fetch.pruneTags true

git describe

Der git describe SH-Befehl findet das neueste Tag, das von einem Commit aus erreicht werden kann. Wenn das Tag auf den Commit verweist, wird nur das Tag angezeigt, andernfalls wird die Anzahl der weiteren Commits an den Tagnamen angehängt. Das Ergebnis ist ein Objektname, der von anderen Git-Befehlen verwendet werden kann, um den Commit zu identifizieren. Angenommen, ihr habt einen Commit-SHA und möchtet wissen, in welcher Version er zuerst veröffentlicht wurde, könnt ihr den folgenden Befehl verwenden:

$ git describe --contains 39ff38d | sed -E 's/[~^][0-9]*//g'
24.1.0