Tagi katika Git: jinsi ya kufanya kazi na git tag na kuweka matoleo ya releases

git tag ni alama yenye jina kwenye commit maalum. Tofauti na tawi, tag haisogei commit mpya zinapoongezwa: v1.2.0 baada ya mwaka mmoja bado itaelekeza kwenye picha ileile ya msimbo. Ndiyo maana tag hutumika kwa releases, na mifumo ya CI/CD mara nyingi huanzisha jenzi na uchapishaji kwa tag mpya.

Tag nyepesi na tag za maelezo

Git ina aina mbili za tag, na tofauti yao ni muhimu.

Kwa releases tumia tag za maelezo: zinaonyesha nani na lini alitoa toleo, na zinaweza kusainiwa.

Jinsi ya kuunda tag

Kwenye commit ya sasa

git tag -a v1.2.0 -m "Toleo 1.2.0: usafirishaji wa ripoti, muda wa API umerekebishwa"

Bila -m, Git itafungua kihariri kwa ujumbe — ni rahisi ikiwa unataka kuandika orodha ya mabadiliko.

Kwenye commit ya zamani

Ulisahau kuweka tag wakati wa release — si tatizo, tag inaweza kuwekwa kwenye commit yoyote:

git log --oneline -5
# 7be41d0 feat: kusafirisha ripoti
# 1c02e8f fix: muda wa ombi kuisha
git tag -a v1.1.0 1c02e8f -m "Toleo 1.1.0"

Tag iliyosainiwa

git tag -s v1.2.0 -m "Toleo 1.2.0"
git tag -v v1.2.0     # hakiki sahihi

Inahitaji ufunguo wa GPG uliowekwa (au SSH ikiwa gpg.format=ssh). GitHub na GitLab zinaonyesha tag kama hizi na alama ya uthibitisho.

Jinsi ya kuona tag

git tag                       # tag zote kwa mpangilio wa alfabeti
git tag -l "v1.*"             # kwa muundo
git tag -n                    # pamoja na mstari wa kwanza wa ujumbe
git tag --sort=-v:refname     # kwa toleo, mpya juu
git show v1.2.0               # data ya tag na commit
git describe --tags           # tag ya karibu zaidi: v1.2.0-3-g7be41d0

Angalia mpangilio: kwa chaguo-msingi v1.10.0 itakuja kabla ya v1.9.0, kwa sababu mistari inalinganishwa herufi kwa herufi. Chaguo --sort=v:refname hupanga kama matoleo.

Matokeo ya git describe yanasomwa hivi: commit tatu baada ya tag v1.2.0, commit ya sasa ni 7be41d0 (herufi g ni git). Ni chanzo kizuri cha nambari ya toleo kwa jenzi kati ya releases.

Jinsi ya kutuma tag kwenye seva

git push ya kawaida haitumi tag — hii ni sababu ya kawaida ya swali "kwa nini tag haipo kwenye GitHub".

git push origin v1.2.0        # tag moja
git push --tags               # tag zote za ndani
git push --follow-tags        # commit + tag za maelezo zinazoelekeza kwenye hizo commit

--follow-tags ni salama zaidi kuliko --tags: haitatuma tag nyepesi za kibinafsi ulizoweka kwa ajili yako. Unaweza kuiwasha kwa chaguo-msingi: git config --global push.followTags true.

Kupakua tag kutoka seva: git fetch --tags. git fetch ya kawaida pia huvuta tag zinazoelekeza kwenye commit zinazopakuliwa.

Jinsi ya kufuta au kuhamisha tag

Kufuta

git tag -d v1.2.0                     # kwenye kompyuta yako
git push origin --delete v1.2.0       # kwenye seva
# njia ya zamani sawa: git push origin :refs/tags/v1.2.0

Kuhamisha tag kwenye commit nyingine

git tag -a -f v1.2.0 <hash-mpya> -m "Toleo 1.2.0"
git push origin -f v1.2.0

Kiufundi inawezekana, lakini kwenye miradi ya umma haipendekezwi kuhamisha tag iliyochapishwa. Waliokwisha kupakua tag hawataisasisha wenyewe: Git haibadilishi tag zilizopo wakati wa fetch bila --force. Matokeo: watu tofauti watakuwa na msimbo tofauti chini ya jina "v1.2.0". Ni bora kutoa v1.2.1.

Jinsi ya kujua ni commit zipi ziliingia kwenye release

Tag zinafaa kama mipaka ya safu katika amri zote za kusoma historia:

git log v1.1.0..v1.2.0 --oneline        # commit kati ya releases
git diff v1.1.0 v1.2.0 --stat           # faili zilizobadilika
git tag --contains 1c02e8f              # commit hii iko kwenye releases zipi
git merge-base --is-ancestor 1c02e8f v1.2.0 && echo "iko kwenye release"

Amri mbili za mwisho zinajibu swali la kawaida la usaidizi: "marekebisho yamefika kwa watumiaji au bado?" Ikiwa marekebisho yako kwenye main pekee na release ilijengwa mapema, git tag --contains itaonyesha orodha tupu, na itakuwa wazi kwamba tag mpya inahitajika.

Mbinu nyingine ni kupakua msimbo wa toleo fulani bila historia: git archive --format=zip -o app-1.2.0.zip v1.2.0. Hivyo hutengenezwa kumbukumbu za kutolewa kwa mteja au kwa jenzi katika mazingira yaliyotengwa.

Jinsi ya kuhamia toleo kwa tag

git switch --detach v1.1.0
# HEAD is now at 1c02e8f fix: muda wa ombi kuisha

Utakuwa kwenye hali ya detached HEAD: unaweza kuangalia na kujenga, lakini commit mpya hazitakuwa za tawi lolote. Ikiwa unataka kurekebisha toleo la zamani, tengeneza tawi kutoka kwenye tag:

git switch -c hotfix/1.1.x v1.1.0
# marekebisho, commit
git tag -a v1.1.1 -m "Marekebisho ya usalama"
git push origin hotfix/1.1.x --follow-tags

Kuhesabu releases: SemVer

Mpangilio wa kawaida wa majina ya tag ni Semantic Versioning: MAJOR.MINOR.PATCH.

• MAJOR hupanda kwa mabadiliko yasiyolingana na API ya zamani: 1.4.2 → 2.0.0.
• MINOR — kipengele kipya kinachobaki kinalingana na cha zamani: 1.4.2 → 1.5.0.
• PATCH — marekebisho ya hitilafu: 1.4.2 → 1.4.3.
• Matoleo ya majaribio huwekwa alama kwa kiambishi: 2.0.0-beta.1, 2.0.0-rc.1.

Kiambishi v (v1.4.2) ni mkataba wa kawaida wa majina ya tag, SemVer yenyewe haihitaji. Jambo kuu ni kuchagua muundo mmoja na kushikamana nao, vinginevyo hati zinazotafuta release ya mwisho zitavunjika.

Tag katika mchakato wa release

Mchakato wa kawaida kwenye timu unaonekana hivi:

1. Mabadiliko yanaunganishwa kwenye main, majaribio yanapita.
2. CHANGELOG na nambari ya toleo kwenye faili za mradi vinasasishwa, ikiwa vimehifadhiwa humo.
3. Tag ya maelezo inawekwa: git tag -a v1.5.0 -m "Toleo 1.5.0".
4. git push origin main --follow-tags.
5. CI inaona tag mpya, inajenga artifacts na kuchapisha release; GitHub na GitLab wanaunda ukurasa wa Release kutoka kwenye tag wenye maelezo na faili.

Hivyo toleo lolote kwenye production linaweza kuhusishwa moja kwa moja na msimbo: tag kwenye jina la jenzi, na git show inaonyesha kilichomo. Na git log v1.4.0..v1.5.0 --oneline inatoa orodha ya mabadiliko kati ya releases kwa maelezo ya toleo.

Maelezo ya release kutoka kwenye tag

Ikiwa ujumbe wa commit ni wazi, tag zinageuza historia kuwa orodha iliyo tayari ya mabadiliko. Release ya mwisho na iliyotangulia zinaweza kupatikana bila kutafuta kwa mkono:

LAST=$(git describe --tags --abbrev=0)
PREV=$(git describe --tags --abbrev=0 "$LAST^")
git log "$PREV..$LAST" --no-merges --pretty=format:"- %s (%h)"
# - feat: kusafirisha ripoti (7be41d0)
# - fix: muda wa ombi kuisha (1c02e8f)

Ikiwa timu inaandika commit kwa mkataba wa Conventional Commits (feat:, fix:, feat!:), nambari ya toleo linalofuata linaweza kuhesabiwa kiotomatiki: fix huongeza PATCH, feat huongeza MINOR, alama ya mshangao au BREAKING CHANGE huongeza MAJOR. Zana maarufu za releases za kiotomatiki zinafanya hivyo: zinaweka tag na kuandika CHANGELOG zenyewe.

Tag na CI/CD

Pipelines kwa kawaida hutofautisha matukio mawili: push kwenye tawi na kuonekana kwa tag. Kwenye tawi zinaendesha majaribio na jenzi ya mazingira ya majaribio, na kwenye tag zinachapisha. Kwenye GitHub Actions inaonekana hivi:

on:
  push:
    tags:
      - "v*.*.*"

Kwenye GitLab CI kazi hiyo inafanywa na kigezo CI_COMMIT_TAG na kanuni rules: - if: $CI_COMMIT_TAG. Jina la tag ndani ya pipeline linakuwa nambari ya toleo la picha ya Docker au kifurushi, kwa hiyo muundo wa tag lazima uwe mkali na unaotabirika.

Hii ni sababu nyingine ya kutohamisha tag: ikiwa pipeline tayari ilichapisha kifurushi 1.2.0 kwenye rejista, kuchapisha tena kwa nambari ileile kwa kawaida hairuhusiwi, na picha yenye tag 1.2.0 itabaki ya zamani kwa watumiaji.

Majina ya tag: yaliyoruhusiwa

Jina la tag linafuata sheria zilezile za jina la tawi: bila nafasi, bila herufi ~ ^ : ? * [, na bila nukta mbili mfululizo. Kistari cha kufyeka kinaruhusiwa, kwa hiyo kwenye monorepo kuna tag kama api/v1.2.0 na web/v3.0.1 — seti moja ya matoleo kwa kila kifurushi. Unaweza kuhakiki jina mapema kwa git check-ref-format "refs/tags/v1.2.0": ikiwa kuna kosa, amri itarudisha msimbo usio sifuri.

Kulinda tag

Kwenye repo za timu, tag za releases zinafaa kulindwa: GitHub na GitLab zinaruhusu kukataza kuunda, kuandika upya na kufuta tag kwa muundo (kwa mfano v*) kwa kila mtu isipokuwa wasimamizi. Hivyo git push --tags ya bahati mbaya kutoka kwenye kompyuta ya mtu mwingine haitachapisha release isiyopangwa, na git push origin --delete ya makosa haitafuta historia ya matoleo.

Makosa ya kawaida

• Tag haipo kwenye seva. Umesahau git push origin <tag> au --follow-tags.
• Tag yenye jina sawa na tawi. Git itatoa onyo refname is ambiguous; tumia kiambishi v kwa tag na majina tofauti.
• Tag kwenye hali isiyocommitiwa. Tag inawekwa kwenye commit, si kwenye faili: mabadiliko ambayo hayajacommitiwa hayataingia kwenye release.
• Tag nyepesi kwa release. Haina mwandishi, tarehe wala ujumbe, na git describe haiioni kwa chaguo-msingi.

Hitimisho

git tag hurekebisha sehemu isiyobadilika kwenye historia: kwa releases unda tag za maelezo kwa git tag -a, zipe majina kwa SemVer, na zitume kwenye seva waziwazi — git push origin <tag> au --follow-tags. Tag zilizochapishwa usizihamishe; toa toleo jipya. Tag pamoja na rebase, stash na cherry-pick zinafundishwa kwa vitendo katika kozi ya Git.