git ready

Taggen

Taggen ist in Git eine großartige Art, um eine bestimmte Version des Codes zu kennzeichnen oder um aus irgendeinem Grund genau einen Commit in deiner Versionsgeschichte zu referenzieren. Dieser Beitrag behandelt die richtigen (und falschen) Wege, wie git tag verwendet wird.

Die wahrscheinlich beste Art einen Tag zu beschreiben ist eine kleine Klebezettelnotiz, die einen Commit kennzeichnet. Sie beinhaltet einen Namen, also etwas ähnliches wie v1.0.0 oder production, und auch eine Nachricht, wenn du möchtest. Git for Computer Scientists visualisiert einen Tag folgendermaßen:

Wie wird ein Tag erzeugt? Einfach git tag v1.0.0, richtig? FALSCH. Das möchtest du gewöhnlich nicht tun. Einige Leute meinen, dass dieser Befehl standardmäßig das Falsche macht. Ohne Argumente erzeugt git tag einen “leichtgewichtigen” Tag, der im Grunde genommen ein Branch ist, der sich nie bewegt. Leichtgewichtige Tags sind dennoch nützlich, zum Beispiel zum Markieren einer bekannten guten (oder schlechten) Version oder zum Markieren einer Reihe von Commits, die du in der Zukunft vielleicht verwenden möchtest. Nichts desto trotz, solltest du diese Art von Tags nicht in ein remote Repository pushen.

Normalerweise übergibst du mindestens die Option -a, um ein unsigniertes Tag zu erzeugen, oder du signierst ein Tag mit deinem GPG-Schlüssel über die Option -s oder -u <key-id>. Sobald das erledigt ist, kannst du git describe benutzen, um zu sehen, wieviele Commits du seit dem letzten oder dem genannten Tag erzeugt hast. Git-fu hat eine schöne Anleitung über die Verwendung dieses Befehls (und verdient auch einen eigenen Tip in der Zukunft!).

Dann erstellen wir einfach mal einen neuen Tag und schauen uns an, wie wir ihn referenzieren können, sogar wenn einige Commits vorgenommen worden sind. Dann pushen wir den Tag in ein remote Repository. Es ist viel einfacher, als du denkst:

$ git tag -a v1.0.0 -m "Creating the first official version."

$ git show v1.0.0 
  tag v1.0.0
  Tagger: Nick Quaranto <nick@quaran.to>
  Date:   Tue Feb 3 20:37:45 2009 -0500

  Creating the first official version.
  commit a8d1b55c5d4bdec843d9942cabf1b678bc1d4eed
  Merge: 00b9675... 1b487b8...
  Author: Nick Quaranto <nick@quaran.to>
  Date:   Sun Nov 30 00:41:08 2008 -0500

      Merge branch 'master' of git@github.com:qrush/config

$ git describe --tags
  v1.0.0

$ touch test
$ git add test
$ git commit -am "Adding test files"
  Created commit a7aafb8: Adding test files
   0 files changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 test

$ git describe --tags
  v1.0.0-1-ga7aafb8

$ git push --tags
  Counting objects: 40, done.
  Compressing objects: 100% (37/37), done.
  Writing objects: 100% (40/40), 29.32 KiB, done.
  Total 40 (delta 15), reused 9 (delta 2)
  To git@github.com:qrush/config.git
   * [new tag]         v1.0.0 -> v1.0.0

Der zweite describe Befehl zeigt uns, dass wir einen Commit vor dem zuletzt vorgenommenen Tag sind. Das ist eine einfache Möglichkeit, um herauszufinden, wieviel Arbeit seit dem letzten Commit erledigt wurde. Die --tags Option wurde hier verwendet, um auch die Tags zu pushen. Aber nur der eine Tag konnte mit git push origin : v1.0.0 gepushed werden. Auf GitHub (oder in deinem remote Repository) solltest du die übertragenen Tags sehen:

Eine kleine Randnotiz, falls du deine übertragenen Tags verschieben oder umbenennen möchtest, macht es dir Git sehr schwer, dies zu veranlassen. Sieh in der Manpage nach. Hier bekommst du eine Erklärung, warum es so kompliziert ist und mit Bedacht verwendet werden sollte.

Wenn du einen einzigartigen Weg für die Integration von Tags in deinen Git-Workflow kennst, teile ihn uns in den Kommentaren mit oder sende uns einen Tip, so dass andere davon lernen können!