Chapters ▾ 2nd Edition

2.6 Git Basics - Tagging

Tagging

Soos die meeste VCS’e, het Git die vermoë om spesifieke punte in 'n bewaarplek (repository) se geskiedenis as belangrik te tag. Gewoonlik gebruik mense hierdie funksionaliteit om vrystellingspunte (release points) te merk (v1.0, v2.0 en so aan). In hierdie afdeling sal jy leer hoe om bestaande tags te lys, hoe om tags te skep en uit te vee, en wat die verskillende tipes tags is.

Jou tags lys

Om die bestaande tags in Git te lys, is eenvoudig. Tik net git tag (met 'n opsionele -l of --list):

$ git tag
v1.0
v2.0

Hierdie opdrag lys die tags in alfabetiese volgorde; die volgorde waarin hulle vertoon word, het geen werklike betekenis nie.

Jy kan ook soek vir tags wat by 'n spesifieke patroon pas. Die Git bron-bewaarplek (source repo), byvoorbeeld, bevat meer as 500 tags. As jy net daarin belangstel om na die 1.8.5-reeks te kyk, kan jy hierdie uitvoer:

$ 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
Note
Om tag-wildcards te lys vereis die -l of --list opsie

As jy net die hele lys van tags wil hê, neem die git tag opdrag implisiet aan dat jy 'n lys wil hê en verskaf een; die gebruik van -l of --list in hierdie geval is opsioneel.

As jy egter 'n wildcard-patroon verskaf om by tag-name te pas, is die gebruik van -l of --list verpligtend.

Tags skep

Git ondersteun twee tipes tags: lightweight (liggewig) en annotated (geannoteer).

'n Lightweight tag is baie soos 'n branch wat nie verander nie — dit is net 'n wyser (pointer) na 'n spesifieke commit.

Annotated tags word egter as volledige objekte in die Git-databasis gestoor. Hulle het 'n kontrolesom (checksum); bevat die tagger se naam, e-pos, en datum; het 'n tag-boodskap; en kan met GNU Privacy Guard (GPG) geteken en geverifieer word. Dit word oor die algemeen aanbeveel dat jy annotated tags skep sodat jy al hierdie inligting kan hê; maar as jy 'n tydelike tag wil hê of om een of ander rede nie die ander inligting wil behou nie, is lightweight tags ook beskikbaar.

Annotated tags

Om 'n annotated tag in Git te skep, is eenvoudig. Die maklikste manier is om -a te spesifiseer wanneer jy die tag opdrag uitvoer:

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

Die -m spesifiseer 'n tag-boodskap, wat saam met die tag gestoor word. As jy nie 'n boodskap vir 'n annotated tag spesifiseer nie, maak Git jou redigeerder (editor) oop sodat jy dit kan intik.

Jy kan die tag-data saam met die commit wat getag is sien deur die git show opdrag te gebruik:

$ 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

Dit wys die tagger-inligting, die datum waarop die commit getag is, en die annotasie-boodskap voordat die commit-inligting gewys word.

Lightweight tags

Nog 'n manier om commits te tag is met 'n lightweight tag. Dit is basies die commit-checksum wat in 'n lêer gestoor word — geen ander inligting word behou nie. Om 'n lightweight tag te skep, moenie enige van die -a, -s, of -m opsies verskaf nie, verskaf net 'n tag-naam:

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

Hierdie keer, as jy git show op die tag uitvoer, sien jy nie die ekstra tag-inligting nie. Die opdrag wys net die commit:

$ 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

Later tag

Jy kan ook commits tag nadat jy verby hulle beweeg het. Veronderstel jou commit-geskiedenis lyk so:

$ 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

Veronderstel nou jy het vergeet om die projek by v1.2 te tag, wat by die “Update rakefile” commit was. Jy kan dit agterna byvoeg. Om daardie commit te tag, spesifiseer jy die commit-checksum (of 'n deel daarvan) aan die einde van die opdrag:

$ git tag -a v1.2 9fceb02

Jy kan sien dat jy die commit getag het:

$ 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 deel

By verstek dra die git push opdrag nie tags oor na remote bedieners nie. Jy sal tags eksplisiet na 'n gedeelde bediener moet push nadat jy hulle geskep het. Hierdie proses is net soos om remote branches te deel — jy kan git push origin <tagnaam> uitvoer.

$ 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

As jy baie tags het wat jy gelyktydig wil op-push, kan jy ook die --tags opsie by die git push opdrag gebruik. Dit sal al jou tags wat nog nie daar is nie, na die remote bediener oordra.

$ 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

Nou, wanneer iemand anders jou bewaarplek (repository) kloon of daaruit pull, sal hulle ook al jou tags kry.

Note
git push push beide tipes tags

git push <remote> --tags sal beide lightweight en annotated tags push. Daar is tans geen opsie om slegs lightweight tags te push nie, maar as jy git push <remote> --follow-tags gebruik sal slegs annotated tags na die remote gepush word.

Tags uitvee

Om 'n tag op jou plaaslike bewaarplek te verwyder, kan jy git tag -d <tagnaam> gebruik. Byvoorbeeld, ons kan ons lightweight tag hierbo as volg verwyder:

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

Let daarop dat dit nie die tag van enige remote bedieners verwyder nie. Daar is twee algemene variasies om 'n tag van 'n remote bediener uit te vee.

Die eerste variasie 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

Die manier om bogenoemde te interpreteer, is om dit te lees as dat die nul-waarde voor die dubbelpunt na die remote tag-naam gepush word, wat dit effektief uitvee.

Die tweede (en meer intuïtiewe) manier om 'n remote tag uit te vee is met:

$ git push origin --delete <tagnaam>

Tags checkout

As jy na die weergawes van lêers waarna 'n tag wys wil kyk, kan jy 'n git checkout van daardie tag doen, alhoewel dit jou bewaarplek in 'n “detached HEAD” toestand plaas, wat 'n paar slegte newe-effekte het:

$ 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

In 'n “detached HEAD” toestand, as jy veranderinge maak en dan 'n commit skep, sal die tag dieselfde bly, maar jou nuwe commit sal nie aan enige branch behoort nie en sal onbereikbaar wees, behalwe deur die presiese commit-hash te gebruik. Dus, as jy veranderinge moet maak — sê nou jy is besig om 'n fout op 'n ouer weergawe reg te maak — sal jy oor die algemeen 'n branch wil skep:

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

As jy dit doen en 'n commit maak, sal jou version2 branch effens anders wees as jou v2.0.0 tag aangesien dit vorentoe sal beweeg met jou nuwe veranderinge, so wees versigtig.