Git
Chapters ▾ 2nd Edition

2.6 Mga Pangunahing Kaalaman sa Git - Pag-tag

Pag-tag

Tulad sa karamihan sa mga VCS, may kakayahan ang Git para mag-tag sa isang tiyak na mga punto sa kasaysayan bilang mahalaga. Karaniwan, ang mga tao ay gumagamit sa kakayahang ito para markahan ang release na mga puntos (v1.0, at iba pa). Sa seksyon na ito, matutunan mo kung paano ilista ang magagamit na mga tag, paano gumawa ng bagong mga tag, at ano ang iba’t ibang mga uri ng mga tag.

Paglista ng Iyong mga Tag

Ang paglista ng mga magagamit na mga tag sa Git ay madali lang. I-type lang git tag (na may opsyonal na -l o --list):

$ git tag
v0.1
v1.3

Ang mga listahan ng mga utos na ito ay nakalista ayon sa alpabetikong pagkasunod-sunod; ang pagkakasunod-sunod kung saan lumilitaw ang mga ito ay walang tunay na kahalagahan.

Maaari ka ring maghanap para sa mga tag na tumutugma sa isang partikular na paterno. Ang Git source na repo, halimbawa, ay naglalaman ng higit sa 500 na mga tag. Kung ikaw lamang ay interesado sa pagtingin sa serye ng 1.8.5, maaari mo itong patakbuhin:

$ 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
Example 3. Ang paglista ng tag na mga wildcards ay nangangailangan ng -l o --list na opsyon

Kung gusto mo lang ang buong listahan ng mga tag, ang pagpapatakbo ng utos na git tag ay nagpapalagay na gusto mo nang isang listahan at nagbibigay sa iyo ng isa; ang paggamit sa -l o --list sa kasong ito ay opsyonal.

Kung, gayunpaman, ikaw ay nagbibigay ng isang wildcard pattern upang itugma ang tag na mga pangalan, ang gamit ng -l o --list ay sapilitan.

Paglikha ng mga Tag

Sinusuportahan ng Git and dalawang uri ng mga tag: ang lightweight at annotated.

Ang lightweight na tag ay sobrang katulad lang ng isang branch na hindi nagbabago — ito ay isang pointer lamang sa isang tiyak na commit.

Ang mga annotated na tag, gayunpaman, ay nakaimbak ng buong mga bagay sa database ng Git. Ang mga ito ay naka-checksum; naglalaman ng pangalan ng nag-tag, email, at petsa; magkaroon ng isang mensahe sa pag-tag; at maaaring mapirmahan at napatunayan na may GNU Privacy Guard (GPG). Sa pangkalahatan inirerekomenda mo na lumikha ng annotated na mga tag kaya maaari kang magkaroon ng lahat ng impormasyon na ito; ngunit kung gusto mo ng isang pansamantalang tag o para sa ilang kadahilanan na ayaw mong panatilihin ang iba pang impormasyon, lightweight na mga tag ay magagamit din.

Annotated na mga Tag

Paglikha ng isang annotated na tag sa Git ay madali lang. Ang pinakamadaling paraan ay ang pagtukoy ng -a kapag pinatakbo mo ang tag na utos:

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

Ang -m ay tinutukoy ang isang mensahe ng pag-tag, na naka-imbak gamit ang tag. Kung wala kang tinukoy na isang mensahe para sa isang annotated tag, ang Git ay naglulunsad ng iyong editor kaya maaari mo itong i-type.

Nakikita mo ang tag na datos na kasama ang commit na na-tag sa pamamagitan ng paggamit ng git show na utos:

$ 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

Na nagpapakita ng impormasyon ng nag-tag, ang petsa ng pag-commit ay na-tag, at ang annotation na mensahe bago magpakita ng commit na impormasyon.

Lightweight na mga Tag

Isa pang paraan upang i-tag ang mga commit ay ang isang lightweight na tag. Ito ay karaniwang gumagawa ng checksum na nakaimbak sa isang file — walang ibang impormasyon na itinabi. Upang lumikha ng isang lightweight na tag, huwag magbigay ng anuman ng -a, -s, o -m na mga opsyon, magbigay lamang ng pangalan ng tag:

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

Sa ngayon, kung papatakbuhin mo ang git show sa tag, hindi mo makikita ang karagdagang impormasyon na tag. Ang utos ay nagpapakita lamang ng commit:

$ 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

Pag-tag Mamaya

Maaari mo ring i-tag ang mga commit pagkatapos mong ilipat ang nakalipas sa kanila. Ipagpalagay na ang iyong commit na kasaysayan ay ganito ang hitsura:

$ 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

Ngayon, ipagpalagay na ikaw ay nakalimot na i-tag ang proyekto sa v1.2, na kung saan ay “updated rakefile” na commit. Maaari mo itong idagdag pagkatapos ng pangyayari. Upang i-tag ang commit, tukuyin mo ang commit na checksum (o bahagi nito) sa dulo ng utos:

$ git tag -a v1.2 9fceb02

Maaari mong makita na mayroon kang na-tag na commit:

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

Pagbabahagi ng mga Tag

Bilang default, ang git push ang utos ay hindi nararapat na maglipat ng mga tag sa remote na mga server. Kailangan mo na tahasang itulak ang mga tag sa isang bumabahaging server pagkatapos na ginawa mo ang mga ito. Itong proseso ay tulad ng pagbabahagi ng remote na mga branch — maaari kang magpatakbo ng git push origin <tagname>.

$ 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

Kung mayroon kang maraming mga tag na nais mong i-push kaagad, maaari mo ring gamitin ang --tags na opsyon sa git push na utos. Ililipat nito ang lahat ng iyong mga tag sa remote server na wala pa doon.

$ 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

Ngayon, kapag may iba pang panggagaya o humihila mula sa iyong repositoryo, makakakuha sila ng lahat ng iyong mga tag din.

Sinusuri ang mga Tag

Kung nais mong tingnan ang mga bersyon sa mga file ng isang tag na tumuturo sa, maaari kang gumawa ng git checkout, bagaman ito ay naglalagay sa iyong repositoryo sa “detached HEAD” na estado, na may ilang masamang mga epekto:

$ 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

Sa “detached HEAD” na estado, kung gumawa ka ng mga pagbabago at pagkatapos ay lumikha ka ng commit, ang tag ay mananatiling pareho, ngunit ang iyong bagong commit ay hindi pagmamay-ari ng anumang branch at hindi maaabot, maliban sa pamamagitan ng eksaktong commit hash. Kaya naman, kung kailangan mong gumagawa ng mga pagbabago — sabihin mo na ikaw ay nag-aayos ng isang bug na nasa mas lumang bersyon, halimbawa — sa pangkalahatan ay nais mong lumikha ng branch:

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

Kung gagawin mo ito at gumawa ng commit, ang iyong version2 na branch ay bahagyang naiiba kaysa sa iyong v2.0.0 na tag dahil ito ay sumusulong sa iyong mga bagong pagbabago, kaya maging maingat.

scroll-to-top