Git Tag Tutorial: Wie man Tags erstellt, verwaltet und verwendet

Erstellen und Verwalten von Git-Tags

Das Erstellen und Verwalten von Git-Tags ist ganz einfach. Schauen wir uns die verschiedenen Arten von Tags an und wie man sie anwendet.

• Um Git-Tags zu verwenden, solltest du Git bereits auf deinem Rechner installiert haben. Du kannst mehr über die Installation von Git im Git Install Tutorial lesen. 
• Eine weitere Voraussetzung ist, dass du ein initialisiertes Git-Repository hast. Mehr dazu erfährst du in Wie man ein Git-Repository initialisiert und einrichtet.

Leichtgewichtige Tags erstellen

Ein Lightweight-Tag ist wie ein Verweis auf einen Commit. Er enthält keine Metadaten, sondern nur den Tag-Namen und den Commit, auf den er zeigt.

Um eine zu erstellen, kannst du sie ausführen: 

git tag v1.0.0

Dieser Befehl erstellt einen Lightweight-Tag, der auf den aktuellen HEAD Commit verweist. 

Du kannst alternativ ein Tag für einen bestimmten Commit erstellen, indem du den Commit-Hash angibst:

git tag v1.0.0 5c5fc06

Leichtgewichtige Tags sind hilfreich für schnelle, lokale Referenzen, vor allem bei Solo-Entwicklungsprojekten oder temporärer Arbeit.

Erstellen von beschrifteten Tags

Kommentierte Tags speichern mehr Informationen, wie den Namen des Taggers, seine E-Mail, das Datum und die Nachricht. Sie werden als vollständige Git-Objekte gespeichert und sind ideal für die Kennzeichnung von offiziellen Veröffentlichungen oder Meilensteinen.

Du kannst eine laufende erstellen: 

git tag -a v1.0.0 -m "Release version 1.0.0"

Dieser Befehl erstellt ein kommentiertes Tag namens v1.0.0 mit der Nachricht "Release version 1.0.0".

Du kannst auch einen bestimmten Commit markieren:

git tag -a v1.0.0 5c5fc06 -m "Tagging older commit"

Kommentierte Tags bieten eine bessere Dokumentation, lassen sich gut mit CI/CD-Tools integrieren und helfen Teams, den Lernpfad transparenter zu verfolgen.

Markieren bestimmter Commits

Manchmal musst du einen Commit markieren, der nicht der neueste ist. Dazu kannst du zunächst die Historie der Commits abrufen und dann den Commit-Hash auswählen, für den du ein Tag erstellen möchtest.

Um den Commit-Hash abzurufen, kannst du Folgendes ausführen:

git log --oneline

Kopiere dann den Commit-Hash aus der Liste:

git tag -a v1.0.0 <commit-hash> -m "Tagging v1.0.0 release"

Überprüfung der erstellten Tags

Um alle Tags in deinem Repository aufzulisten, verwende:

git tag

Wenn du z.B. nur Versionen filtern willst, die mit v1. beginnen, verwende:

git tag -l 'v1.*'

Um Details zu einem bestimmten Tag anzuzeigen, führe aus:

git show v1.0.0

Arbeiten mit Git Tags

Wenn du Git-Tags erstellt hast, musst du sie oft teilen, aktualisieren oder mit ihnen interagieren, um sie in deinen Entwicklungs- oder Veröffentlichungsprozess einzubinden. Dieser Abschnitt behandelt die häufigsten Aufgaben bei der Arbeit mit Tags in lokalen und entfernten Repositories. 

Tags in ein entferntes Repository verschieben

Tags werden nicht automatisch in entfernte Repositories übertragen, wenn du git push aufrufst. Du musst sie explizit anschieben.

Um einen einzelnen Tag zu verschieben:

git push origin v1.0.0

Um alle Tags auf einmal zu pushen:

git push --tags

Tags müssen gepusht werden, damit deine Teammitgliederoder CI/CD-Pipelines auf siezugreifen können. Tags werden oft auch als Auslöser für die Bereitstellung verwendet, vor allem bei versionierten Releases. Mehr darüber, wie du Zweige pushen und ziehen kannst, erfährst du im Git Push and Pull Tutorial .

Löschen von Tags

Wenn du einen Tag löschen willst, kannst du das sowohl lokal als auch aus der Ferne tun.

Um sie lokal zu löschen, führe Folgendes aus:

git tag -d v1.0.0

Um dann denselben Tag aus dem entfernten Repository zu löschen:

git push origin --delete v1.0.0

Du kannst den Tag auch direkt auf GitHub oder in der Web-UI von GitLab löschen. 

>Wenn du mehr über GitHub und seine Nutzung erfahren möchtest, empfehle ich dir die Kursees GitHub Foundations und GitHub Concepts.

Tags auschecken

Du kannst dein Repository auf den Status eines bestimmten Tags auschecken, indem du es ausführst:

git checkout v1.0.0

Dies versetzt dich jedoch in einen losgelösten HEAD Zustand. Das bedeutet, dass du nicht mehr in einem Zweig bist und dass neue Commits zu keinem Zweig gehören, es sei denn, du erstellst explizit einen:

git checkout -b hotfix-v1.0.0

Das Auschecken eines bestimmten Tags hilft beim Debuggen oder Prüfen einer bestimmten Release-Version, ohne deinen aktuellen Entwicklungszweig zu beeinflussen. Sie wird auch verwendet, um deine Produktionsanwendung aus einer bestimmten Version zu bauen, zum Beispiel wenn ein Docker-Image erstellt werden muss.

Markierung nach einer Übertragung

Wenn du ein Tag aktualisieren musst, z.B. indem du es auf einen anderen Commit umstellst oder die Nachricht änderst, kannst du einfach eine Aktualisierung erzwingen, indem du den Befehl ausführst:

git tag -f -a v1.0.0 5c5fc06 -m "retagging"

Du kannst denselben Vorgang auch ohne einen Commit-Hash ausführen, um das Tag einfach zum aktuellen HEAD hinzuzufügen.

>Wenn du einen schnellen Überblick über die traditionellen Git-Befehle brauchst, empfehle ich dir das Complete Git Cheat Sheet.

Best Practices für die Verwendung von Git-Tags

Zu wissen, wie man Tags erstellt und verwaltet, ist eine Sache, sie effektiv zu nutzen, eine andere. Wenn du sie klug einsetzt, können Tags deinen Arbeitsablauf, deine Dokumentation und die Kommunikation im Team verbessern.

Tags für die Versionierung verwenden

Tags eignen sich perfektfür die semantische Versionierung, diedie empfohlene Methode für die Versionierung deiner Veröffentlichungen ist.

Bei der semantischen Versionierung folgen deine Versionsnummern dem Format MAJOR.MINOR.PATCH, zum Beispiel v.1.2.0.

MAJOR Versionen sind für umfangreichere und bahnbrechende Änderungen, während MINOR Versionen für neu hinzugefügte Funktionen und PATCH für Fehlerbehebungen sind.

Die semantische Versionierung ist sehr leistungsfähig. Es macht den Umfang der Änderungen deutlich, hilft den Entwicklern, die Kompatibilität zu verstehen, und funktioniert gut mit automatisierten Tools wie CI/CD-Triggern.

Halte dich an eine einheitliche Namenskonvention. Entscheide dich für ein Muster (z.B. immer mit v beginnen) und befolge es in allen deinen Veröffentlichungen.

Freigaben kennzeichnen

Tags sind ideal, um wichtige Phasen deines Projekts zu markieren. Hier sind einige hilfreiche Tag-Typen, die du in Betracht ziehen kannst:

• v1.0.0-alpha: Interne Testversion
• v1.0.0-beta: Öffentliche Beta-Version
• v1.0.0: Endgültige Produktionsfreigabe

Wenn du diese Phasen mit Tags versiehst, kannst du Test-Builds leichter mit anderen teilen, zu früheren Versionen zurückkehren und eine saubere Historie der Produktionseinsätze führen. 

Du kannst den Prozess noch weiter verbessern, indem du kommentierte Tags für Veröffentlichungen verwendest, um den richtigen Kontext und die Dokumentation zu erfassen.

Vermeiden von übermäßiger Verwendung von Tags

So praktisch und leistungsfähig Tags auch sind, sie können nutzlos werden, wenn sie zu oft verwendet werden. Tags sollten nur sinnvolle Punkte in der Geschichte deines Projekts markieren, wie stabile Versionen, die Fertigstellung wichtiger Funktionen, Meilensteine oder Fristen. 

Wenn du jeden Commit mit Tags versiehst, wird dein Repository unübersichtlich und der Zweck der schnellen Navigation verfehlt. Halte es sauber und zielgerichtet!

Eine gute Faustregel ist, dass es wahrscheinlich keinen Tag braucht, wenn du es nicht einsetzen oder ankündigen würdest.

Fehlersuche bei Git Tags

Selbst mit den besten Praktiken wirst du bei der Arbeit mit Git-Tags manchmal auf Probleme stoßen, besonders wenn du mit Teams arbeitest oder mit entfernten Repositories synchronisierst. In diesem Abschnitt wird beschrieben, wie du die häufigsten Probleme lösen kannst.

Umgang mit abgetrenntem HEAD-Status

Wenn du einen bestimmten Tag auscheckst, indem du:

git checkout v1.0.0

Git versetzt dich, wie bereits erwähnt, in einen losgelösten HEAD Zustand. Das bedeutet, dass du nicht auf einem Zweig bist. Wenn du also einen Commit machst, gehört er zu keinem Zweig und kann verloren gehen, wenn du nicht handelst. 

Du kannst das Problem beheben, indem du einen Zweig mit folgendem Befehl erstellst:

git checkout -b hotfix-v1.0.0

Jetzt arbeitest du an einem Zweig und kannst wie gewohnt Änderungen übertragen und veröffentlichen.

Lösen von Tag-Konflikten

Es kann zu Konflikten kommen, wenn derselbe Tag-Name auf verschiedene lokale und entfernte Commits verweist. 

Das passiert oft, wenn du ein Tag lokal löschst und neu erstellst oder jemand anderes ein Tag erzwingt.

Es gibt zwei Möglichkeiten, dieses Problem zu lösen.

Option 1: Lösche und schiebe den Tag erneut

git tag -d v1.0.0
git push origin --delete v1.0.0
git tag -a v1.0.0 -m "Corrected tag"
git push origin v1.0.0

Option 2: Erzwinge die Aktualisierung des Tags

Wenn du sicher bist, dass dein lokaler Tag der richtige ist und du die Erlaubnis hast:

git push origin -f v1.0.0

Aber sei vorsichtig mit dieser Option, denn das Erzwingen von Änderungen kann die Änderungen anderer überschreiben. Verwende sie nur, wenn du dir sicher bist oder nachdem du mit deinem Team kommuniziert hast.

Fazit

Git-Tags sind ein ziemlich mächtiges Werkzeug, wenn man sie richtig einsetzt. In diesem Lernprogramm hast du gelernt:

• Was Git-Tags sind und wann man sie verwendet
• Wie du Git-Tags in deinem Repository anwendest
• Best Practices für die Verwendung von Git-Tags
• Wie man häufige Probleme bei der Arbeit mit Git-Tags behebt

Ganz gleich, ob du Modelle für maschinelles Lernen veröffentlichst, Updates für ein Datenprodukt herausgibst oder im Team zusammenarbeitest, Tags helfen dir, wichtige Momente in der Zeitleiste deines Projekts zu markieren. Sie sorgen für Ordnung, sind reproduzierbar und lassen sich leicht wiederherstellen oder einsetzen.

Ich verwende Git-Tags ständig. Sie ersparen mir viel Zeit, da ich auf stabile Versionen zurückgreifen kann, wenn Bugs auftauchen oder automatisierte CI/CD-Workflows auslösen. Ich verwende sie, um Docker-Images für Produktions-Builds zu taggen und zu versionieren und so sicherzustellen, dass alles, was ich ausliefere, vollständig nachvollziehbar und dokumentiert ist.

Also fang noch heute an, Tags zu verwenden und verändere deinen Git-Workflow!