guides

Ein Git-Tag ist eine benannte Referenz, die auf einen bestimmten Commit in einem Repository zeigt. Während ein Commit durch einen langen, schwer zu merkenden Hash identifiziert wird, gibt ein Tag diesem genauen Punkt in der Historie einen kurzen, gut lesbaren Namen. Tags werden am häufigsten verwendet, um Release-Punkte zu markieren, sodass ein Name wie v1.0.0 auf den genauen Zustand des Codes verweist, der als diese Version ausgeliefert wurde.

Der wesentliche Unterschied zwischen einem Tag und einem Branch besteht darin, dass sich ein Tag nicht bewegt. Ein Branch ist ein Zeiger, der bei jedem neuen Commit weiterrückt und stets die neueste Arbeit verfolgt. Ein Tag ist fest: Sobald man es an einen Commit anhängt, zeigt es weiterhin auf genau diesen Commit, auch wenn die Entwicklung darüber hinaus fortschreitet. Genau das ist bei einem Release erwünscht, denn die Bedeutung von v1.0.0 sollte sich nach der Veröffentlichung nie mehr ändern.

Leichte gegenüber annotierten Tags

Git unterstützt zwei Arten von Tags: leichte Tags und annotierte Tags. Ein leichtes Tag ist kaum mehr als ein Name, der direkt auf einen Commit zeigt, ohne dass zusätzliche Informationen daneben gespeichert werden. Es lässt sich schnell erstellen und eignet sich gut als persönliches Lesezeichen, hält aber nicht fest, wer es erstellt hat oder warum.

Ein annotiertes Tag wird als vollständiges Objekt in der Git-Datenbank gespeichert. Es hält den Namen der Person fest, die das Tag erstellt hat, das Erstellungsdatum und eine Tag-Nachricht, ganz ähnlich wie ein Commit seinen Autor und seine Nachricht festhält. Annotierte Tags können außerdem mit GPG signiert werden, sodass andere überprüfen können, dass ein Release-Tag wirklich von Ihnen stammt. Für öffentliche Releases sind annotierte Tags wegen dieser zusätzlichen Metadaten und der Möglichkeit zu signieren im Allgemeinen die empfohlene Wahl.

Tags erstellen und pushen

Tags zu erstellen ist unkompliziert. Wird git tag mit einem Namen und ohne weitere Optionen ausgeführt, entsteht ein leichtes Tag auf dem aktuellen Commit. Fügt man die Option -a hinzu, wie in git tag -a v1.0.0 -m 'Release 1.0.0', entsteht ein annotiertes Tag mit einer Nachricht. Man kann auch einen älteren Commit taggen, indem man dessen Hash ans Ende des Befehls setzt, was nützlich ist, wenn man erst im Nachhinein bemerkt, dass ein bestimmter Commit der eigentliche Release-Punkt war.

• Ein Tag benennt einen bestimmten Commit; anders als ein Branch bewegt es sich nach dem Setzen nicht mehr.
• Leichtes Tag: nur ein Name, der auf einen Commit zeigt, ohne zusätzliche Metadaten.
• Annotiertes Tag: ein vollständiges Objekt mit Autor, Datum und Nachricht, das mit GPG signiert werden kann.
• Erstellen mit git tag v1.0.0 (leicht) oder git tag -a v1.0.0 -m '...' (annotiert).
• Tags werden nicht standardmäßig gepusht: mit git push origin <tag> oder git push --tags senden.
• Tags markieren Releases, oft als SemVer vX.Y.Z, und lösen häufig CI/CD und Release-Seiten aus.

Ein Punkt, der Neulinge überrascht, ist, dass Tags nicht automatisch geteilt werden. Wenn Sie git push ausführen, werden Ihre Branches auf dem Remote aktualisiert, doch Ihre Tags bleiben lokal, sofern Sie sie nicht ausdrücklich senden. Ein einzelnes Tag pushen Sie mit git push origin gefolgt vom Tag-Namen, oder Sie senden alle Ihre Tags auf einmal mit git push --tags. Diesen Schritt zu vergessen ist ein häufiger Grund dafür, dass ein Release-Tag auf dem Rechner eines Entwicklers erscheint, im gemeinsamen Repository aber fehlt.

Tags, Versionierung und Release-Automatisierung

Tags fügen sich natürlich in ein Versionsschema ein. Viele Projekte folgen der Semantischen Versionierung, bei der eine Version die Form MAJOR.MINOR.PATCH hat, und jedes Release wird als passendes Tag wie v2.4.1 erfasst. Da das Tag unveränderlich ist, kann später jeder genau dieses Tag auschecken und den Code so wiederherstellen, wie er für diese Version aussah, was die Grundlage reproduzierbarer Releases bildet.

Tags treiben auch einen großen Teil der Automatisierung an. Pipelines für Continuous Integration und Deployment werden häufig so konfiguriert, dass sie ausgelöst werden, sobald ein neues Tag gepusht wird, sodass das Taggen eines Commits als v1.2.0 diese Version automatisch baut, testet und veröffentlicht. Plattformen, die Repositories hosten, verwandeln Tags oft in Release-Seiten und hängen jeder getaggten Version Notizen und herunterladbare Artefakte an. So wird ein kleiner, unveränderlicher Zeiger zum Anker für einen ganzen Release-Prozess.

Sicher mit Tags arbeiten

Weil ein Tag nur eine Referenz ist, lässt es sich günstig und sicher verwenden. Tags aufzulisten, nachzusehen, was ein annotiertes Tag aussagt, oder den Code an einem bestimmten Tag auszuchecken, sind allesamt Nur-Lese-Operationen, die Ihre laufende Arbeit nicht stören. Ein Tag lokal zu löschen ist ebenfalls einfach, doch ein bereits gepushtes und von anderen genutztes Tag zu löschen sollte mit Bedacht geschehen, da Personen und Pipelines bereits davon abhängen könnten.

Zusammenfassung

Kurz gesagt ist ein Git-Tag eine stabile Beschriftung für einen Moment in der Historie Ihres Projekts. Leichte Tags sind schnelle persönliche Markierungen, während annotierte Tags eine Urheberschaft, eine Nachricht und optionale Signaturen tragen, die sie für öffentliche Releases geeignet machen. In Verbindung mit einem Versionsschema und auf das gemeinsame Remote gepusht, verwandeln Tags einen nicht zu merkenden Commit-Hash in eine dauerhafte, überprüfbare Referenz für eine bestimmte Version Ihrer Software.