Close

git tag

In dit document worden het Git-concept van taggen en de opdracht git tag besproken. Tags zijn verwijzingen die naar specifieke punten in de geschiedenis van Git verwijzen. Taggen wordt over het algemeen gebruikt om een punt in de geschiedenis vast te leggen dat wordt gebruikt voor een gemarkeerde versie (d.w.z. v1.0.1). Een tag is net een branch die niet verandert. In tegenstelling tot branches hebben tags, nadat ze zijn aangemaakt, geen verdere geschiedenis van commits meer. Ga voor meer informatie over branches naar de pagina git branch. In dit document worden de verschillende soorten tags, hoe je tags maakt, alle tags opsomt, tags verwijdert, tags deelt en meer behandeld.


Een tag aanmaken


Voer de volgende opdracht uit om een nieuwe tag te maken:

git tag <tagname>

Vervang de < tagnaam > door een semantische id voor de status van de repo op het moment dat de tag werd aangemaakt. Een veelgebruikt patroon is het gebruik van versienummers, zoals git tag v1.4. Git ondersteunt twee verschillende soorten tags, geannoteerde en lichte tags. In het vorige voorbeeld is een lichte tag gemaakt. Lichte tags en geannoteerde tags verschillen in de hoeveelheid bijbehorende metagegevens die ze opslaan. Je kunt geannoteerde tags het beste beschouwen als openbaar en lichte tags als privé. Op geannoteerde tags worden extra metagegevens opgeslagen, zoals de naam van de tagger, het e-mailadres en de datum. Dit zijn belangrijke gegevens voor een openbare release. Lichte tags zijn in wezen 'bladwijzers' voor een commit: ze vormen een naam en een verwijzing naar een commit en zijn handig om snelle links naar relevante commits te maken.

Annotated tags


Geannoteerde tags worden als volledige objecten opgeslagen in de Git-database. Nogmaals, op geannoteerde tags worden extra metagegevens opgeslagen, zoals de naam van de tagger, het e-mailadres en de datum. Geannoteerde tags hebben een tagbericht, net als commits een commitbericht hebben. Om veiligheidsredenen kunnen geannoteerde tags bovendien worden ondertekend en geverifieerd met GNU Privacy Guard (GPG). Het is het beste om bij taggen in git geannoteerde tags te verkiezen boven lichte tags, zodat je over alle bijbehorende metagegevens beschikt.

git tag -a v1.4

Als je deze opdracht uitvoert, wordt een nieuwe geannoteerde tag gemaakt, met de id v1.4. De opdracht opent vervolgens de geconfigureerde standaardteksteditor om te vragen om verdere invoer van metagegevens.

git tag -a v1.4 -m "my version 1.4"

Het uitvoeren van deze opdracht is vergelijkbaar met de vorige aanroep, maar aan deze versie van de opdracht worden de optie -m en een bericht doorgegeven. Dit is een handige methode, vergelijkbaar met git commit -m, waarbij onmiddellijk een nieuwe tag wordt aangemaakt en de lokale tekstverwerker niet wordt geopend in plaats van het doorgegeven bericht op te slaan met de optie -m.

Git-logo
gerelateerd materiaal

Git cheat sheet

Logo Bitbucket
Oplossing bekijken

Git leren met Bitbucket Cloud

Lightweight tags


git tag v1.4-lw

Als je deze opdracht uitvoert, wordt een lichte tag gemaakt, met de id v1.4. Lichte tags worden gemaakt zonder de opties -a, -s en -m. Lichte tags maken een nieuwe tag-checksum en slaan deze op in de map .git/ van de repo van het project.

Listing tags


Voer het volgende uit om de opgeslagen tags in een repo weer te geven:

git tag

Dit levert een lijst met tags op:

v0.10.0
    v0.10.0-rc1
    v0.11.0
    v0.11.0-rc1
    v0.11.1
    v0.11.2
    v0.12.0
    v0.12.0-rc1
    v0.12.1
    v0.12.2
    v0.13.0
    v0.13.0-rc1
    v0.13.0-rc2

Om de lijst met tags te verfijnen kan de optie -l worden doorgegeven een wildcard-expressie:

$ git tag -l *-rc*
    v0.10.0-rc1
    v0.11.0-rc1
    v0.12.0-rc1
    v0.13.0-rc1
    v0.13.0-rc2
    v0.14.0-rc1
    v0.9.0-rc1
    v15.0.0-rc.1
    v15.0.0-rc.2
    v15.4.0-rc.3

This previous example uses the -l option and a wildcard expression of -rc which returns a list of all tags marked with a -rc prefix, traditionally used to identify release candidates.

Tagging old commits


De voorgaande voorbeelden van taggen hebben acties op impliciete commits aangetoond. Standaard zal git tag op de commit een tag aanmaken waarnaar HEAD verwijst. Als alternatief kan de git tag als referentie worden doorgegeven aan een specifieke commit. Hiermee wordt de doorgegeven commit getagd in plaats van standaard HEAD. Voer de opdracht git log uit om een lijst van oudere commits te verzamelen.

$ git log --pretty=oneline
    15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'feature'
    a6b4c97498bd301d84096da251c98a07c7723e65 add update method for thing
    0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
    6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'

Als je een git log uitvoert, krijg je een lijst met commits. In dit voorbeeld kiezen we de meest gecommitte Merge branch 'feature' voor de nieuwe tag. We hebben een verwijzing nodig naar de SHA-hash voor commit om door te geven aan Git:

git tag -a v1.2 15027957951b64cf874c3557a0f3547bd83b3ff6

Door de bovenstaande opdracht van de git tag uit te voeren wordt een nieuwe geannoteerde commit aangemaakt, met de id v1.2, voor de commit die we in het vorige voorbeeld van de git log hebben geselecteerd.

ReTagging/Replacing old tags


Als je probeert een tag te maken met dezelfde id als een bestaande tag, genereert Git een foutmelding zoals:

fatal: tag 'v0.4' already exists

Als je bovendien een oudere commit probeert te taggen met een bestaande tag-id, genereert Git dezelfde foutmelding.

In het geval dat je een bestaande tag moet updaten, moet de optie -f FORCE worden gebruikt.

git tag -a -f v1.4 15027957951b64cf874c3557a0f3547bd83b3ff6

Als je de bovenstaande opdracht uitvoert, wordt de commit 15027957951b64cf874c3557a0f3547bd83b3ff6 toegewezen aan de tag-id v1.4. Dit vervangt alle bestaande content voor de tag v1.4.

Sharing: Pushing tags to remote


Het delen van tags is vergelijkbaar met het pushen van branches. git push pusht standaard geen tags. Tags moeten expliciet worden doorgegeven aan git push.

$ git push origin v1.4
    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@bitbucket.com:atlasbro/gittagdocs.git
     * [new tag]         v1.4 -> v1.4

Geef de optie --tags door aan de opdracht git push om meerdere tags tegelijk te pushen. Wanneer een andere gebruiker een repo kloont of pullt, ontvangt diegene de nieuwe tags.

Checking out tags


You can view the state of a repo at a tag by using the git checkout command.

git checkout v1.4

Bovenstaande opdracht checkt de tag v1.4 uit. Dit plaatst de repo in een aparte HEAD-status. Dit betekent dat de tag niet wordt bijgewerkt als er wijzigingen worden aangebracht. Hierdoor wordt een nieuw, afzonderlijke commit aangemaakt. Deze nieuwe, afzonderlijke commit maakt geen deel uit van een branch en is enkel rechtstreeks bereikbaar via de SHA-hash van commits. Daarom is het goed om elke keer een nieuwe branch aan te maken als je veranderingen aanbrengt in een aparte HEAD-staat.

Deleting tags


Tags verwijderen is heel eenvoudig. Door de optie -d en een tag-id door te geven aan git tag, wordt de geïdentificeerde tag verwijderd.

$ git tag
    v1
    v2
    v3
    $ git tag -d v1
    $ git tag
    v2
    v3

In dit voorbeeld wordt de git tag uitgevoerd om een lijst met tags weer te geven met v1, v2, v3. Vervolgens wordt de git tag -d v1 uitgevoerd, waardoor de tag v1 wordt verwijderd.

Samenvatting


To recap, Tagging is an additional mechanism used to create a snap shot of a Git repo. Tagging is traditionally used to create semantic version number identifier tags that correspond to software release cycles. The git tag command is the primary driver of tag: creation, modification and deletion. There are two types of tags; annotated and lightweight. Annotated tags are generally the better practices as they store additional valuable meta data about the tag. Additional Git commands covered in this document were git push, and git checkout. Visit their corresponding pages for discussion on their extended use.


Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Mensen die samenwerken met een muur vol tools

Bitbucket-blog

Toelichting DevOps

DevOps-leertraject

Demo Den Feature-demo's met Atlassian-experts

Hoe Bitbucket Cloud werkt met Atlassian Open DevOps

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up