Tags und Releases: Lightweight- versus annotierte Tags und wie sie sich verbreiten

Worum es geht

Die Dokumentation zu git-tag unterscheidet zwei Arten. Ein Lightweight-Tag ist schlicht ein Name für ein Objekt, meist einen Commit, gespeichert als Referenz. Ein annotierter Tag (erstellt mit -a, -s oder -u) ist ein eigenes Tag-Objekt, das Erstellungsdatum, Name und E-Mail des Taggers, eine Nachricht und optional eine kryptografische Signatur enthält. Die Dokumentation hält fest, dass annotierte Tags für Releases gedacht sind, während Lightweight-Tags für private oder vorübergehende Markierungen gedacht sind, und dass einige Befehle wie git describe Lightweight-Tags deshalb standardmässig ignorieren.

Tags sind nicht Teil eines Branches. git push überträgt Branches; --tags pusht alles unter refs/tags, und --follow-tags (oder push.followTags) pusht nur annotierte Tags, die auf mitgepushte Commits zeigen.

Warum es wichtig ist

Der Release-Tag ist das, worauf Build-Systeme, Changelog-Generatoren und auf git describe basierende Versionsstrings sich stützen. Ein Lightweight-Tag hält nicht fest, wer den Release wann geschnitten hat, kann nicht signiert werden und ist für git describe unsichtbar, sofern nicht --tags ergänzt wird – was dann zwischen Maschinen unterschiedliche Versionsstrings erzeugt. Ein Tag, der zu spät oder gar nicht gepusht wird, lässt die CI einen ungetaggten Commit bauen.

So wird es angewendet

• Releases mit git tag -a v2.3.0 -m "Release 2.3.0" erstellen, oder mit -s signieren; die Zusammenfassung der Release Notes in die Nachricht schreiben.
• Explizit pushen: git push origin v2.3.0, oder push.followTags setzen, damit annotierte Tags mit dem Branch mitwandern. --tags in Skripten vermeiden, weil es auch jeden lokalen Experimentier-Tag mitpusht.
• Die CI auf Tag-Pushes auslösen lassen, die auf v* passen, und die Version aus git describe --tags --dirty oder allein aus dem Tag ableiten.
• Einen gepushten Tag als unveränderlich behandeln. Die Dokumentation rät im Abschnitt zum erneuten Taggen dazu, den Fehler einzugestehen und einen neuen Namen zu verwenden; sie hält fest, dass Git Tags nicht hinter dem Rücken der Nutzer ändert, sodass Klone, die den Tag bereits geholt haben, das alte Ziel behalten.
• Tag-Namen einem einzigen Schema folgen lassen (v1.2.3, nie gemischt mit 1.2.3 oder release-1.2.3), damit Sortierung und Globbing funktionieren.

Stolpersteine

Tags wandern getrennt von Branches, sodass ein Tag in einem Klon existieren und in einem anderen fehlen kann, bis er explizit gepusht oder geholt wird. Tags zu signieren, ohne den Schlüssel zu veröffentlichen, gibt Prüfenden nichts, was sie kontrollieren könnten. Ein Tag benennt ein Objekt, das meist, aber nicht zwingend, ein Commit ist, was Werkzeuge überrascht, die von Commits ausgehen. Plattform-«Releases» sind Metadaten, die an einem Tag hängen; vor dem Verlass auf beides prüfen, ob das Löschen eines Releases auch den Tag entfernt.

Release-Tags schützen

Ein über Tags ausgelöster Release macht das Erstellen eines Tags zu einer Release-Berechtigung, und in einem frischen Repository hat sie jeder mit Schreibzugriff, unabhängig vom Branch-Schutz. Das Muster (v*) mit Tag-Rulesets auf GitHub oder geschützten Tags auf GitLab einschränken, sodass nur Release-Maintainer es erstellen oder löschen können, und den Release-Job vor der Veröffentlichung prüfen lassen, dass der getaggte Commit auf der begutachteten Historie liegt: git merge-base --is-ancestor "$GITHUB_SHA" origin/main || exit 1 (oder der Release-Branch). Den Tag zusätzlich signieren, damit die im Signierungs-Methodik-Artikel dieses Wikis beschriebene Prüfung auch für Releases gilt, und die Signierschlüssel dort veröffentlichen, wo der Build sie abrufen kann.