Close

git tag

In diesem Dokument behandeln wir das Konzept des Tagging bei Git und den Befehl git tag. Tags sind Referenzen, die auf bestimmte Zeitpunkte im Git-Verlauf verweisen. In der Regel werden mit Tags bestimmte Punkte im Verlauf erfasst, die für einen markierten Versions-Release (z. B. v1.0.1) verwendet werden. Ein Tag ähnelt einem Branch, der sich nicht ändert. Im Gegensatz zu Branches haben Tags nach der Erstellung keinen weiteren Verlauf mit Commits. Weitere Informationen zu Branches findest du auf der git branch-Seite. In diesem Dokument gehen wir u. a. auf die verschiedenen Arten von Tags ein und erläutern, wie du Tags erstellst, auflistest, löschst, freigibst usw.


Erstellen eines Tags


Führe folgenden Befehl aus, um ein neues Tag zu erstellen:

git tag <tagname>

Ersetze < tagname > durch eine semantische Kennung für den Zustand des Repositorys zum Zeitpunkt der Tag-Erstellung. Häufig werden hierfür Versionsnummern wie git tag v1.4 verwendet. Git unterstützt zwei Arten von Tags: annotierte und Lightweight-Tags. Im vorherigen Beispiel wurde ein Lightweight-Tag erstellt. Lightweight-Tags und annotierte Tags unterscheiden sich im Umfang der gespeicherten begleitenden Metadaten. Als Best Practice solltest du annotierte Tags als "öffentlich" und Lightweight-Tags als "privat" betrachten. Bei annotierten Tags werden zusätzliche Metadaten wie der Name und die E-Mail-Adresse des Taggers sowie das Datum gespeichert. Diese Daten sind für öffentliche Releases wichtig. Lightweight-Tags sind im Prinzip "Lesezeichen" für einen Commit und somit nur ein Name und ein Verweis auf einen Commit. Sie eignen sich zur schnellen Erstellung von Links zu relevanten Commits.

Annotated tags


Annotierte Tags werden in der Git-Datenbank als vollständige Objekte gespeichert. Zur Erinnerung: Sie enthalten zusätzliche Metadaten wie den Namen und die E-Mail-Adresse des Taggers sowie das Datum. Ähnlich wie bei Commits und Commit-Nachrichten gibt es bei annotierten Tags eine Tagging-Nachricht. Außerdem können annotierte Tags zu Sicherheitszwecken mit GNU Privacy Guard (GPG) signiert und verifiziert werden. Es empfiehlt sich, beim Taggen in Git annotierte Tags gegenüber Lightweight-Tags zu bevorzugen, damit alle zugehörigen Metadaten vorhanden sind.

git tag -a v1.4

Wenn du diesen Befehl ausführst, wird ein neues annotiertes Tag mit der Kennung v1.4 erstellt. Dann wird der konfigurierte Standard-Texteditor mit der Aufforderung zum Eingeben weiterer Metadaten geöffnet.

git tag -a v1.4 -m "my version 1.4"

Dieser Befehl ähnelt dem vorherigen Aufruf, allerdings werden bei dieser Version des Befehls die Option -m und eine Nachricht übergeben. Ähnlich wie git commit -m ist dies eine praktische Methode, um sofort ein neues Tag zu erstellen, das Öffnen des lokalen Texteditors zu übergehen und stattdessen die mit der Option -m übergebene Nachricht zu speichern.

Git-Logo
Zugehöriges Material

Git-Merkzettel

Bitbucket-Logo
Lösung anzeigen

Git kennenlernen mit Bitbucket Cloud

Lightweight tags


git tag v1.4-lw

Mit diesem Befehl erstellst du ein Lightweight-Tag mit der Kennung v1.4-lw. Beim Erstellen von Lightweight-Tags werden die Optionen -a, -s und -m nicht verwendet. Zusammen mit dem Lightweight-Tag wird eine neue Prüfsumme erstellt und im .git/-Verzeichnis des Projekt-Repositorys gespeichert.

Listing tags


Führe folgenden Befehl aus, um eine Liste der in einem Repository gespeicherten Tags abzurufen:

git tag

Hiermit wird eine Liste der Tags ausgegeben:

v0.10.0
    v0.10.0-rc1
    v0.11.0
    v0.11.0-rc1
    v0.11.1
    v0.11.2
    v0.12.0
    v0.12.0-rc1
    v0.12.1
    v0.12.2
    v0.13.0
    v0.13.0-rc1
    v0.13.0-rc2

Wenn du die Liste der Tags eingrenzen möchtest, kannst du die Option -l in Verbindung mit einem Platzhalterausdruck übergeben:

$ git tag -l *-rc*
    v0.10.0-rc1
    v0.11.0-rc1
    v0.12.0-rc1
    v0.13.0-rc1
    v0.13.0-rc2
    v0.14.0-rc1
    v0.9.0-rc1
    v15.0.0-rc.1
    v15.0.0-rc.2
    v15.4.0-rc.3

Im Beispiel oben wurde die Option -l zusammen mit dem Platzhalterausdruck -rc verwendet. Die Ausgabe ist eine Liste aller mit dem Präfix -rc versehenen Tags, das üblicherweise zur Kennzeichnung von release candidates (Release-Kandidaten) verwendet wird.

Tagging old commits


Mit den bisherigen Tagging-Beispielen haben wir Vorgänge für implizite Commits demonstriert. Standardmäßig erstellt git tag ein Tag für den Commit, auf den der HEAD verweist. Alternativ kannst du git tag als Referenz an einen bestimmten Commit übergeben, um den angegebenen Commit statt des HEAD zu taggen. Wenn du eine Liste älterer Commits abrufen möchtest, verwende den Befehl git log.

$ git log --pretty=oneline
    15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'feature'
    a6b4c97498bd301d84096da251c98a07c7723e65 add update method for thing
    0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
    6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'

Die Ausführung von git log gibt eine Liste der Commits aus. In diesem Beispiel wählen wir den obersten Commit Merge branch 'feature' für das neue Tag aus. Wir müssen dazu auf den Commit-SHA-Hash für Git verweisen:

git tag -a v1.2 15027957951b64cf874c3557a0f3547bd83b3ff6

Mit dem oben gezeigten Aufruf des Befehls git tag wird ein neuer annotierter Commit mit der Kennung v1.2 für den Commit erstellt, den wir im vorherigen git log-Beispiel ausgewählt haben.

ReTagging/Replacing old tags


Wenn du versuchst, ein Tag mit derselben Kennung wie bei einem bereits vorhandenen Tag zu erstellen, gibt Git einen Fehler aus. Die Meldung lautet in etwa:

fatal: tag 'v0.4' already exists

Solltest du versuchen, einen älteren Commit mit einer vorhandenen Tag-Kennung zu taggen, gibt Git denselben Fehler aus.

Wenn du ein vorhandenes Tag aktualisieren musst, ist dies nur mit der Option -f (FORCE) möglich.

git tag -a -f v1.4 15027957951b64cf874c3557a0f3547bd83b3ff6

Mit dem Befehl oben wird der Commit 15027957951b64cf874c3557a0f3547bd83b3ff6 der Tag-Kennung v1.4 zugeordnet. Vorhandene Inhalte des Tags v1.4 werden dabei überschrieben.

Sharing: Pushing tags to remote


Das Freigeben von Tags funktioniert ähnlich wie das Pushen von Branches. Standardmäßig werden mit git push keine Tags gepusht. Tags müssen explizit an git push übergeben werden.

$ git push origin v1.4
    Counting objects: 14, done.
    Delta compression using up to 8 threads.
    Compressing objects: 100% (12/12), done.
    Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
    Total 14 (delta 3), reused 0 (delta 0)
    To git@bitbucket.com:atlasbro/gittagdocs.git
     * [new tag]         v1.4 -> v1.4

Wenn du mehrere Tags gleichzeitig pushen möchtest, verwende die Option --tags für den Befehl git push. Wenn nun ein anderer Benutzer ein Repository klont oder pullt, erhält er die neuen Tags.

Checking out tags


You can view the state of a repo at a tag by using the git checkout command.

git checkout v1.4

Mit dem oben verwendeten Befehl wird das Tag v1.4 ausgecheckt. Dadurch wechselt das Repository in einen Status mit losgelöstem HEAD. Vorgenommene Änderungen führen dann nicht zu einer Aktualisierung des Tags. Stattdessen wird ein neuer losgelöster Commit erstellt. Dieser neue losgelöste Commit ist nicht Teil eines Branch und nur über den SHA-Hash des Commits zu erreichen. Aus diesem Grund empfiehlt es sich, immer einen neuen Branch zu erstellen, wenn du im Status mit losgelöstem HEAD Änderungen vornimmst.

Deleting tags


Das Löschen von Tags ist einfach: Du musst nur die Option -d und eine Tag-Kennung an git tag übergeben, um das entsprechende Tag zu löschen.

$ git tag
    v1
    v2
    v3
    $ git tag -d v1
    $ git tag
    v2
    v3

In diesem Beispiel haben wir mit git tag eine Liste der Tags mit v1, v2 und v3 aufgerufen. Mit git tag -d v1 haben wir dann das v1-Tag gelöscht.

Zusammenfassung


To recap, Tagging is an additional mechanism used to create a snap shot of a Git repo. Tagging is traditionally used to create semantic version number identifier tags that correspond to software release cycles. The git tag command is the primary driver of tag: creation, modification and deletion. There are two types of tags; annotated and lightweight. Annotated tags are generally the better practices as they store additional valuable meta data about the tag. Additional Git commands covered in this document were git push, and git checkout. Visit their corresponding pages for discussion on their extended use.


Diesen Artikel teilen
Nächstes Thema

Lesenswert

Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.

Mitarbeiter arbeiten mit unzähligen Tools zusammen

Bitbucket-Blog

Abbildung: DevOps

DevOps-Lernpfad

Demo Den: Feature-Demos mit Atlassian-Experten

So funktioniert Bitbucket Cloud mit Atlassian Open DevOps

Melde dich für unseren DevOps-Newsletter an

Thank you for signing up