2.6 Git Basics - Taggen (Labelen)

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

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 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.

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

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:

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

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:

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:

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

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:

Je kunt zien dat je commit getagd hebt:

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.

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.

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

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:

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>:

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:

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:

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:

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.