Kapitel ▾ 2. Auflage

2.6 Git Grundlagen - Tagging

Tagging

Wie die meisten VCSs verfügt Git über die Fähigkeit, bestimmte Punkte im Verlauf eines Repositories als wichtig zu markieren. Typischerweise nutzen die Leute diese Funktionalität, um Release-Punkte zu kennzeichnen (v1.0, v2.0 und so weiter). In diesem Abschnitt lernen Sie, wie Sie vorhandene Tags auflisten, wie Sie Tags erstellen und löschen und welche verschiedenen Arten von Tags es gibt.

Vorhandene Tags auflisten

Das Auflisten vorhandener Tags in Git ist unkompliziert. Geben Sie einfach git tag (mit optional -l oder --list) ein.

$ git tag
v1.0
v2.0

Dieser Befehl listet die Tags alphabetisch auf; die Reihenfolge, in der sie angezeigt werden, ist von keiner wirklichen Bedeutung.

Sie können auch nach Tags suchen, die einem bestimmten Muster entsprechen. Das Git-Quellcode-Repository enthält beispielsweise mehr als 500 Tags. Wenn Sie sich nur für die 1.8.5er-Serie interessieren, können Sie Folgendes ausführen:

$ git tag -l "v1.8.5*"
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5
Hinweis
Wildcards für Tags erfordern die Option -l oder --list

Wenn Sie nur die gesamte Liste der Tags wünschen, nimmt der Befehl git tag implizit an, dass Sie eine Liste wünschen, und liefert diese. Die Verwendung von -l oder --list ist in diesem Fall optional.

Wenn Sie jedoch ein Wildcard-Muster zur Übereinstimmung mit Tag-Namen angeben, ist die Verwendung von -l oder --list zwingend erforderlich.

Tags erstellen

Git unterstützt zwei Arten von Tags: leichte (lightweight) und kommentierte (annotated).

Ein leichter Tag ist sehr ähnlich einem Branch, der sich nicht ändert – er ist nur ein Zeiger auf einen bestimmten Commit.

Kommentierte Tags hingegen werden als vollständige Objekte in der Git-Datenbank gespeichert. Sie sind checksummiert; enthalten den Namen, die E-Mail und das Datum des Taggers; haben eine Tagging-Nachricht; und können mit GNU Privacy Guard (GPG) signiert und verifiziert werden. Es wird generell empfohlen, kommentierte Tags zu erstellen, damit Sie all diese Informationen haben können; aber wenn Sie einen temporären Tag wünschen oder aus irgendeinem Grund die anderen Informationen nicht behalten möchten, sind leichte Tags ebenfalls verfügbar.

Kommentierte Tags

Das Erstellen eines kommentierten Tags in Git ist einfach. Der einfachste Weg ist, -a anzugeben, wenn Sie den Befehl tag ausführen.

$ git tag -a v1.4 -m "my version 1.4"
$ git tag
v0.1
v1.3
v1.4

Das -m gibt eine Tagging-Nachricht an, die mit dem Tag gespeichert wird. Wenn Sie keine Nachricht für einen kommentierten Tag angeben, startet Git Ihren Editor, damit Sie diese eingeben können.

Sie können die Tag-Daten zusammen mit dem Commit, der getaggt wurde, mit dem Befehl git show anzeigen.

$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date:   Sat May 3 20:19:12 2014 -0700

my version 1.4

commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    Change version number

Das zeigt die Informationen des Taggers, das Datum, an dem der Commit getaggt wurde, und die Annotationsnachricht an, bevor die Commit-Informationen angezeigt werden.

Leichte Tags

Eine andere Möglichkeit, Commits zu taggen, ist mit einem leichten Tag. Dies ist im Grunde die Commit-Checksumme, die in einer Datei gespeichert ist – es werden keine weiteren Informationen aufbewahrt. Um einen leichten Tag zu erstellen, geben Sie keine der Optionen -a, -s oder -m an, sondern nur einen Tag-Namen.

$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5

Dieses Mal, wenn Sie git show für den Tag ausführen, sehen Sie keine zusätzlichen Tag-Informationen. Der Befehl zeigt nur den Commit an.

$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    Change version number

Tags nachträglich erstellen

Sie können auch Commits taggen, nachdem Sie sie passiert haben. Nehmen wir an, Ihr Commit-Verlauf sieht so aus:

$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 Create write support
0d52aaab4479697da7686c15f77a3d64d9165190 One more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc Add commit function
4682c3261057305bdd616e23b64b0857d832627b Add todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a Create write support
9fceb02d0ae598e95dc970b74767f19372d61af8 Update rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc Commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a Update readme

Nun nehmen wir an, Sie haben vergessen, das Projekt mit v1.2 zu taggen, was bei dem Commit "Update rakefile" war. Sie können dies nachträglich hinzufügen. Um diesen Commit zu taggen, geben Sie die Commit-Checksumme (oder einen Teil davon) am Ende des Befehls an.

$ git tag -a v1.2 9fceb02

Sie können sehen, dass Sie den Commit getaggt haben.

$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5

$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Feb 9 15:32:16 2009 -0800

version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@gee-mail.com>
Date:   Sun Apr 27 20:43:35 2008 -0700

    Update rakefile
...

Tags teilen

Standardmäßig überträgt der Befehl git push keine Tags an Remote-Server. Sie müssen Tags nach ihrer Erstellung explizit auf einen gemeinsamen Server pushen. Dieser Prozess ist genau wie das Teilen von Remote-Branches – Sie können git push origin <tagname> ausführen.

$ git push origin v1.5
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@github.com:schacon/simplegit.git
 * [new tag]         v1.5 -> v1.5

Wenn Sie viele Tags haben, die Sie auf einmal pushen möchten, können Sie auch die Option --tags für den Befehl git push verwenden. Dies überträgt alle Ihre Tags auf den Remote-Server, die dort noch nicht vorhanden sind.

$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
 * [new tag]         v1.4 -> v1.4
 * [new tag]         v1.4-lw -> v1.4-lw

Nun, wenn jemand anderes Ihr Repository klont oder von dort pulled, erhält er auch all Ihre Tags.

Hinweis
git push pusht beide Arten von Tags

git push <remote> --tags pusht sowohl leichte als auch kommentierte Tags. Es gibt derzeit keine Option, nur leichte Tags zu pushen, aber wenn Sie git push <remote> --follow-tags verwenden, werden nur kommentierte Tags auf den Remote-Server gepusht.

Tags löschen

Um einen Tag in Ihrem lokalen Repository zu löschen, können Sie git tag -d <tagname> verwenden. Zum Beispiel könnten wir unseren obigen leichten Tag wie folgt entfernen:

$ git tag -d v1.4-lw
Deleted tag 'v1.4-lw' (was e7d5add)

Beachten Sie, dass dies den Tag nicht von Remote-Servern entfernt. Es gibt zwei gängige Varianten, um einen Tag von einem Remote-Server zu löschen.

Die erste Variante ist git push <remote> :refs/tags/<tagname>

$ git push origin :refs/tags/v1.4-lw
To /git@github.com:schacon/simplegit.git
 - [deleted]         v1.4-lw

Die obige Zeile kann so interpretiert werden, dass der Nullwert vor dem Doppelpunkt auf den Remote-Tag-Namen gepusht wird, wodurch dieser effektiv gelöscht wird.

Die zweite (und intuitivere) Methode, einen Remote-Tag zu löschen, ist mit

$ git push origin --delete <tagname>

Tags auschecken

Wenn Sie die Versionen von Dateien anzeigen möchten, auf die ein Tag verweist, können Sie einen git checkout dieses Tags durchführen. Dies versetzt Ihr Repository jedoch in den "detached HEAD"-Zustand, was einige unerwünschte Nebenwirkungen hat.

$ git checkout v2.0.0
Note: switching to 'v2.0.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final

$ git checkout v2.0-beta-0.1
Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final
HEAD is now at df3f601... Add atlas.json and cover image

Im "detached HEAD"-Zustand, wenn Sie Änderungen vornehmen und dann einen Commit erstellen, bleibt der Tag unverändert, aber Ihr neuer Commit gehört zu keinem Branch und ist unerreichbar, außer über den genauen Commit-Hash. Daher, wenn Sie Änderungen vornehmen müssen – sagen wir, Sie beheben einen Fehler in einer älteren Version – möchten Sie im Allgemeinen einen Branch erstellen.

$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'

Wenn Sie dies tun und einen Commit erstellen, wird Ihr version2-Branch leicht von Ihrem v2.0.0-Tag abweichen, da er sich mit Ihren neuen Änderungen vorwärts bewegt, also seien Sie vorsichtig.