Einführung

Git unterstützt zwei Arten von Tags: Lightweight, die nur Refs sind, die auf Commits zeigen, und Annotated, die vollständige Git-Objekte mit Metadaten sind. Verwenden Sie für Releases Annotated Tags.

Erstellen

git tag v1.0.0                          # Lightweight
git tag -a v1.0.0 -m "1.0 GA"           # Annotated
git tag -s v1.0.0 -m "Signed"           # GPG-signiert annotated
git tag -a v1.0.0 a1b2c3d -m "..."     # einen bestimmten Commit taggen

Was Annotated Tags speichern

git cat-file -t v1.0.0
# tag
git cat-file -p v1.0.0
# object <commit-sha>
# type commit
# tag v1.0.0
# tagger Ada <[email protected]> 1714300000 +0000
#
# 1.0 GA

Ein Annotated Tag ist ein eigenes Objekt. Es hat einen eigenen, vom referenzierten Commit verschiedenen SHA, einen Tagger und ein Datum, eine Nachricht und eine optionale Signatur.

Was Lightweight Tags nicht speichern

Ein Lightweight Tag ist nur refs/tags/v1.0.0, der einen Commit-SHA enthält. Es gibt keine Nachricht, keinen Tagger, keine Signatur. git describe, git tag -v und viele CI-Release-Tools nehmen Annotated Tags an und verhalten sich mit Lightweight Tags seltsam.

Inspizieren

git show v1.0.0
git tag -l --format='%(refname:short) %(objecttype) %(taggername) %(subject)'

Lightweight Tags zeigen commit als Objekttyp; Annotated Tags zeigen tag.

Signieren und Verifizieren

git tag -s v1.0.0 -m "Signed"
git tag -v v1.0.0
# gpg: Good signature from "Ada Lovelace <[email protected]>"

SSH-Signierung wird in modernem Git ebenfalls unterstützt:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git tag -s v1.1.0 -m "SSH-signed"

Wählen

• Verwenden Sie Annotated für Releases, alles, was Sie veröffentlichen, alles, was Sie signieren.
• Verwenden Sie Lightweight für Ad-hoc-Lokal-Lesezeichen (z. B. "diesen Commit vor dem Rebasen merken").

Tags pushen

git push origin v1.0.0
git push origin --tags
git push --follow-tags         # nur Annotated Tags, von gepushten Commits aus erreichbar

--follow-tags ignoriert absichtlich Lightweight Tags, was üblicherweise erwünscht ist.

Tag-Dereferenzierung

Viele Befehle dereferenzieren einen Annotated Tag automatisch zu dem Commit, auf den er zeigt; manche nicht. Verwenden Sie ^{}, um Dereferenzierung in Skripten zu erzwingen:

git rev-parse v1.0.0           # SHA des Tag-Objekts (annotated)
git rev-parse v1.0.0^{}        # SHA des Commits, auf den er zeigt
git rev-parse v1.0.0^{commit}  # gleichbedeutend, mit Typprüfung
git for-each-ref --format='%(refname:short) %(*objectname)' refs/tags

Der Platzhalter %(*objectname) liefert den dereferenzierten Commit für Tags und ist leer für Nicht-Tag-Refs. Dieses Muster ist essentiell für Release-Skripte, die einen Commit-SHA aus einem Tag-Namen brauchen.

Häufige Fehler

Releases mit reinem git tag v1.0 taggen und Tagger/Datum/Nachricht in Audit-Logs verpassen. Übergeben Sie immer -a oder -s. Einen veröffentlichten Tag auf einen neuen Commit verschieben ("Force-Tag"); nachgelagerte Nutzer haben den alten SHA bereits gecacht und übernehmen die Änderung möglicherweise nicht. Vergeben Sie stattdessen v1.0.1. Lightweight Tags als benannte Lesezeichen über ein Team hinweg verwenden; wenn Sie teilen müssen, bevorzugen Sie Branches oder Annotated Tags. Schließlich: Erwarten, dass git describe ohne Annotated Tags funktioniert; standardmäßig zählt es nur die annotated (--tags aktiviert lightweight, mit Vorbehalten).