Git
Chapters ▾ 2nd Edition

2.6 Git Basics - Taggen (Labelen)

Taggen (Labelen)

Zoals de meeste VCS’en, heeft Git de mogelijkheid om specifieke punten in de historie als belangrijk te taggen (labelen). Over het algemeen gebruiken mensen deze functionaliteit om versie-punten te markeren (v1.0, enz.). In deze paragraaf zul je leren hoe de aanwezige tags te tonen, hoe nieuwe tags te creëren en te verwijderen, en wat de verschillende typen tags zijn.

Jouw tags laten zien

De aanwezige tags in Git laten zien is heel eenvoudig. Type gewoon git tag (met optioneel -l of --list):

$ git tag
v1.0
v2.0

Dit commando toont de tags in alfabetische volgorde; de volgorde waarin ze verschijnen heeft geen echte betekenis.

Je kunt ook zoeken op tags met een bepaald patroon. De Git bron-repository, bijvoorbeeld, bevat meer dan 500 tags. Als je alleen geïnteresseerd bent om naar de 1.8.5 serie te kijken, kun je dit uitvoeren:

$ 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
Noot
Tag wildcards uitlijsten vereist het gebruik van de -l of --list optie

Als je alleen de hele lijst van tags wilt zien, gaat het commando git tag er impliciet van uit dat je een uitlijsting wilt en geeft er een; het gebruik van -l of --list is in dat geval optioneel. Echter, als je een wildcard patroon meegeeft om tag-namen te filteren, is het gebruik van -l of --list verplicht.

Tags creëren

Git gebruikt twee tags: lightweight (lichtgewicht) en annotated (beschreven).

Een lightweight tag vertoont veel overeenkomst met een branch die niet verandert: het is slechts een wijzer naar een specifieke commit.

Annotated tags daarentegen, zijn als volwaardige objecten in de Git database opgeslagen. Ze worden gechecksumd, bevatten de naam van de tagger, e-mail en datum, hebben een tag boodschap, en kunnen gesigneerd en geverifieerd worden met GNU Privacy Guard (GPG). Het wordt over het algemeen aangeraden om annotated tags te maken zodat je al deze informatie hebt; maar als je een tijdelijke tag wilt of om een of andere reden de andere informatie niet wilt houden, dan zijn er lightweight tags.

Annotated tags

Een annotated tag in Git maken is eenvoudig. Het makkelijkste is om de -a optie te specificeren als je het tag commando uitvoert:

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

De -m specificeert een tag boodschap, die bij de tag opgeslagen wordt. Als je geen boodschap voor een beschreven tag opgeeft, dan opent Git je editor zodat je deze in kunt typen.

Je kunt de tag data zien, samen met de commit die getagd was, door het git show commando te gebruiken:

$ 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

    changed the version number

Dat toont informatie over de tagger, de datum waarop de commit getagd is, en de beschrijvende boodschap alvorens de commit informatie te laten zien.

Lichtgewicht tags

Een andere manier om commits te taggen zijn lichtgewicht (lightweight) tags. Eigenlijk is dit de checksum van de commit die in een bestand opgeslagen wordt, er wordt geen enkele andere informatie bewaard. Om een lightweight tag te maken, geef je geen van de de -a, -s of -m opties mee:

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

Dit keer, als je git show op de tag runt, krijg je niet de extra tag informatie te zien. Het commando laat alleen de commit zien:

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

    changed the version number

Later taggen

Je kunt ook commits taggen als je al veel verder bent. Stel dat je commit historie er als volgt uit ziet:

$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme

En stel nu dat je bent vergeten het project op v1.2 te taggen, wat bij de commit van “updated rakefile” was. Je kunt dat achteraf toevoegen. Om die commit te taggen, moet je de commit checksum (of een deel daarvan) toevoegen aan het eind van het commando:

$ git tag -a v1.2 9fceb02

Je kunt zien dat je commit getagd hebt:

$ 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

    updated rakefile
...

Tags delen

Standaard zal het git push commando geen tags naar remote servers versturen. Je zult expliciet tags naar een gedeelde server moeten pushen, nadat je ze gemaakt hebt. Dit proces is hetzelfde als remote branches delen - je kunt git push origin <tagnaam> uitvoeren.

$ 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

Als je veel tags hebt die je ineens wilt pushen, kun je ook de --tags optie aan het git push commando toevoegen. Dit zal al je tags, die nog niet op de remote server zijn, in één keer er naartoe sturen.

$ 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

Als nu iemand anders van jouw repository kloont of pullt, dan zullen zij al jouw tags ook krijgen.

Noot
git push pusht beide soorten tags

Het pushen van tags met git push <remote> --tags maakt geen onderscheid tussen lichtgewicht en beschreven tags, er is geen eenvoudige optie die je in staat stelt slechts een type voor pushen te selecteren.

Tags verwijderen

Om een tag uit je lokale repository te verwijderen, kan je git tag -d <tagnaam> gebruiken. Als voorbeeld, we kunnen onze lichtgewicht tag hierboven als volgt verwijderen:

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

Merk op dat dit niet de tag van enig remote server verwijdert. Er zijn twee gangbare varianten om een tag van een remote server te verwijderen.

De eerste variant is git push <remote> :refs/tags/<tagnaam>:

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

De manier om het bovenstaande te intepreteren is om het te lezen als dat de null-waarde van voor de dubbele punt wordt gepusht naar de naam van de remote tag, wat neerkomt op het verwijderen ervan.

De tweede (en meer intuïtieve) manier om een remote tag te verwijderen is met:

$ git push origin --delete <tagname>

Tags uitchecken

Als je de lijst van bestandsversies wilt zien waar een tag naar verwijst, kan je een git checkout doen, maar dit zet je repository wel in een “detached HEAD” status, wat een aantal nadelige bijeffecten heeft:

$ git checkout 2.0.0
Note: checking out '2.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 -b with the checkout command again. Example:

  git checkout -b <new-branch>

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

$ git checkout 2.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

In “detached HEAD” status, als je wijzigingen maakt en dan een commit maakt, blijft de tag hetzelfde, maar je nieuwe commit zal niet tot enige branch behoren en zal onbereikbaar zijn, behalve bij de exacte hash van de commit. Dus als je wijzigingen moet maken - stel dat je een bug op een oudere versie oplost - zal je over het algemeen een branch willen maken:

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

Als je dit doet en dan een commit maakt, zal je version2-branch een beetje anders zijn dan je v2.0.0 tag omdat het voortgaat met jouw nieuwe wijzigingen, dus wees voorzichtig.

scroll-to-top