Sāksim ar skaidrojumu par to, kas ir git birka.

1

Tagu izmanto, lai apzīmētu un atzīmētu konkrētu nosūtījumu vēsturē.
To parasti izmanto, lai atzīmētu izdošanas punktus (piemēram, v1.0 utt.).

Lai gan tags var izskatīties līdzīgs atzaram, tags tomēr nemainās.
Tā norāda tiešā veidā uz konkrētu kopiju vēsturē.

2

Jūs nevarēsiet pārbaudīt tagus, ja tie nebūs lokāli jūsu repozitorijā, tāpēc vispirms jums ir jāpaņem tagi no jūsu lokālā repozitorija.

Vispirms pārliecinieties, ka tagi eksistē lokāli, veicot

# --all will fetch all the remotes.
# --tags will fetch all tags as well
git fetch --all --tags --prune

Pēc tam pārbaudiet tagu, palaižot

git checkout tags/ -b 

Tā vietā, lai ierakstītu origin, izmantojiet prefiksu tags/.

Šajā paraugā ir 2 tagi 1.0 & amp; versija 1.1, tos var pārbaudīt, izmantojot jebkuru no šīm iespējām:

git checkout A  ...
git checkout version 1.0  ...
git checkout tags/version 1.0  ...

Visi iepriekš minētie piemēri būs vienādi, jo tags ir tikai norāde uz konkrēto kopiju.

3 izcelsme: https://backlog.com/git-tutorial/img/post/stepup/capture_stepup4_1_1.png

Kā apskatīt visu tagu sarakstu?

# list all tags
git tag

# list all tags with given pattern ex: v-
git tag --list 'v-*'

Kā izveidot tagus?

Ir 2 veidi, kā izveidot birku:

# lightweight tag 
git tag 

# annotated tag
git tag -a

Atšķirība starp abiem veidiem ir tāda, ka, veidojot anotētu birku, jūs varat pievienot metadatus tāpat kā git commit:
vārdu, e-pastu, datumu, komentāru & amp; parakstu.

4

Kā dzēst tagus?

# delete any given tag
git tag -d 

# Don't forget to remove the deleted tag form the server with push tags

Kā klonēt konkrētu tagu?

Lai paņemtu konkrētas birkas saturu, varat izmantot checkout komandu.
Kā paskaidrots iepriekš, tagi ir tādi paši kā jebkurš cits commits, tāpēc mēs varam izmantot checkout un SHA-1 vietā vienkārši aizstāt to ar tag_name.

1. iespēja:

# Update the local git repo with the latest tags from all remotes
git fetch --all

# checkout the specific tag
git checkout tags/ -b 

Variants 2:

Izmantojot komandu klons

Tā kā git atbalsta pietiekamu klonēšanu, pievienojot komandai klonēt komandu --nozare, mēs varam izmantot atzarojuma nosaukuma vietā birkas nosaukumu. Git zina, kā "pārtulkot" doto SHA-1 uz attiecīgo nodošanu.

# Clone a specific tag name using git clone 
 git clone  --branch=

git clone --branch=

--zacirknis var ņemt arī tagus un atdalīt HEAD pie šīs nodošanas iegūtajā repozitorijā..

Kā pievienot tagus?

git push --tags

Visu tagu izvietošana:

git push --tags 

Anotēto tagu un pašreizējās vēstures ķēdes tagu izspiešanai izmantojiet::

git push --follow-tags

Šis karodziņš --follow-tags izstumj gan nosūtījumus, gan tikai tagus, kas ir abi:

• Anotētās birkas (lai jūs varētu izlaist vietējās/temp build birkas)
• Sasniedzamie tagi (priekšteči) no pašreizējā zara (kas atrodas vēsturē)

Sākot ar Git 2.4, to var iestatīt, izmantojot konfigurāciju

git config --global push.followTags true

(Šīs atbildes rakstīšana prasīja laiku, un codeWizard's atbilde ir pareiza pēc mērķa un būtības, bet ne pilnībā pilnīga, tāpēc es to vienalga publicēšu.)

Nav tādas lietas kā "attālināta Git tag". Ir tikai "tagi". Es to visu norādīju nevis tāpēc, lai būtu pedantisks, 1 bet gan tāpēc, ka vienkāršie Git lietotāji šajā jautājumā ir ļoti neizpratnē, un Git dokumentācija nav pārāk noderīga2 iesācējiem. (Nav skaidrs, vai neskaidrības rodas sliktas dokumentācijas dēļ, vai sliktā dokumentācija rodas tāpēc, ka tas jau pēc būtības ir nedaudz mulsinoši, vai kā citādi.) Ir ir "attālinātās filiāles", pareizāk tās saukt par "attālinātās sekošanas filiālēm", bet ir vērts atzīmēt, ka tās patiesībā ir vietējās vienības. Tomēr attālināto atzarojumu nav (ja vien jūs tos (no jauna) neizgudrojat). Pastāv tikai vietējās birkas, tāpēc, lai to izmantotu, birka ir jāiegūst lokāli. Vispārējā forma konkrētu nodevumu nosaukumiem - ko Git sauc par references - ir jebkura virkne, kas sākas ar refs/. Virkne, kas sākas ar refs/heads/, nosauc atzaru; virkne, kas sākas ar refs/remotes/, nosauc attālās sekošanas atzaru; un virkne, kas sākas ar refs/tags/, nosauc tagu. Nosaukums refs/stash ir atsauce uz krātuvi (kā to izmanto git stash; ievērojiet, ka nav pēdējās slīpsvītras). Ir daži neparasti īpašo gadījumu nosaukumi, kas nesākas ar refs/: HEAD, ORIG_HEAD, MERGE_HEAD un CHERRY_PICK_HEAD ir arī nosaukumi, kas var attiekties uz konkrētām nodevām (lai gan HEAD parasti satur zara nosaukumu, t. i., satur ref: refs/heads/branch). Bet parasti atsauces sākas ar refs/. Viena no lietām, ar ko Git to padara neskaidru, ir tā, ka tas ļauj izlaist refs/ un bieži vien arī vārdu aiz refs/. Piemēram, jūs varat izlaist refs/heads/ vai refs/tags/, atsaucoties uz vietējo atzaru vai tagu - un patiesībā jums jāizlaiž refs/heads/, pārbaudot vietējo atzaru! To var darīt vienmēr, kad rezultāts ir nepārprotams, vai - kā mēs tikko norādījām - kad tas ir jādara (piemēram, git checkout branch). Tiesa, atsauces pastāv ne tikai jūsu repozitorijā, bet arī attālinātos repozitorijos. Tomēr Git ļauj piekļūt attālā repozitorija atsaucēm tikai ļoti konkrētos laikos, proti, fetch un push operāciju laikā. Lai tās redzētu, var izmantot arī git ls-remote vai git remote show, taču fetch un push ir interesantāki kontakta punkti.

Refspecs

Lai pārsūtītu atsauces starp vietējo un attālo repozitoriju, fetch un push laikā Git izmanto virknes, ko sauc par refspecs. Tādējādi tieši šajos brīžos, izmantojot refspecs, divi Git repozitoriji var savstarpēji sinhronizēties. Kad nosaukumi ir sinhronizēti, jūs varat izmantot to pašu nosaukumu, ko izmanto kāds, kas atrodas attālinātajā repozitorijā. Tomēr fetch ir kāda īpaša maģija, un tā ietekmē gan filiāļu, gan tagu nosaukumus. Jums vajadzētu domāt par git fetch kā par jūsu Git, lai izsauktu (vai, iespējams, sūtītu īsziņu) citu Git - "attālo"- un veiktu ar to sarunu. Šīs sarunas sākumā attālā iekārta uzskaita visas savas atsauces: visu, kas atrodas refs/heads/, un visu, kas atrodas refs/tags/, kā arī visas citas atsauces, kas tai ir. Jūsu Git tās skenē un (pamatojoties uz parasto fetch refspec) pārdēvē to filiāles. Aplūkosim parasto refspec attālajam ar nosaukumu origin:

$ git config --get-all remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
$ 

Šis refspec uzdod jūsu Git ņemt katru nosaukumu, kas atbilst refs/heads/*, t. i., katru attālinātā atzaru, un mainīt tā nosaukumu uz refs/remotes/origin/*, t. i., saglabāt atbilstīgo daļu tādu pašu, mainot atzara nosaukumu (refs/heads/) uz attālinātā atzara nosaukumu (refs/remotes/, īpaši refs/remotes/origin/). Ar šo refspec* palīdzību origin's atzari kļūst par jūsu attālinātās sekošanas atzariem attālajam origin``. Filiāles nosaukums kļūst par attālinātās sekošanas filiāles nosaukumu, iekļaujot attālinātās, šajā gadījumāorigin, filiāles nosaukumu. Plusa zīme+refspec priekšpusē nosaka "force" karogu, t.i., jūsu attālās sekošanas filiāle tiks atjaunināta, lai tā atbilstu attālās filiāles nosaukumam, neatkarīgi no tā, kas nepieciešams, lai to saskaņotu. (Bez+` atzarojuma atjauninājumi aprobežojas ar "ātrās pārsūtīšanas" izmaiņām, un tagu atjauninājumi tiek vienkārši ignorēti kopš Git versijas 1.8.2 vai līdzīgas - pirms tam tika piemēroti tie paši ātrās pārsūtīšanas noteikumi).

Tags

Bet kā ir ar tagiem? Tām nav atsauces specifikācijas - vismaz ne pēc noklusējuma. Jūs varat to iestatīt, un tādā gadījumā refspec forma ir jūsu ziņā; vai arī varat palaist git fetch --tags. Izmantojot -tags, refspec pievieno refs/tags/*:refs/tags/*, t. i., tas pārnes visas tagus (bet neatjaunina tavu tagu, ja tev jau ir tags ar šo nosaukumu, neņemot vērā, ko saka attālinātais tags Rediģēts, 2017. gada janvāris: no Git 2.10, testēšana liecina, ka --tags piespiedu kārtā atjaunina jūsu tagus no attālinātā's tagiem, it kā refspec lasītu +refs/tags/*:refs/tags/*; iespējams, tā ir atšķirīga uzvedība salīdzinājumā ar agrāko Git versiju). Ievērojiet, ka šeit nenotiek pārdēvēšana: ja attālinātajā origin ir tags xyzzy, bet jums nav, un jūs git fetch origin "refs/tags/*:refs/tags/*", jūsu repozitorijam tiks pievienots refs/tags/xyzzy (norādot uz to pašu commit, kas attālajā). Ja izmantojat +refs/tags/*:refs/tags/*, tad jūsu birka xyzzy, ja jums tāda ir, tiek *aizvietota ar birku no origin. Tas nozīmē, ka + piespiedu karodziņš refspec nozīmē "aizstāt manu atsauces'vērtību ar to, ko mans Git saņem no sava Git".

Automātiskās birkas ielādes ielādes iegūšanas laikā

Vēsturisku iemeslu dēļ,3 ja neizmantojat ne --tags opciju, ne --no-tags opciju, git fetch veic īpašu darbību. Atcerieties, ka iepriekš mēs teicām, ka attālais sāk ar to, ka jūsu lokālajam Git tiek parādītas visas tā atsauces neatkarīgi no tā, vai jūsu lokālais Git vēlas tās redzēt vai nē.4 Jūsu Git šajā brīdī ņem vērā visas redzamās birkas. Pēc tam, kad tas sāks lejupielādēt visus nodevumu objektus, kas tam nepieciešami, lai apstrādātu to, ko tas iegūst, ja kādam no šiem nodevumiem ir tāds pats ID kā kādam no šiem tagiem, git pievienos šo tagu - vai šos tagus, ja vairākiem tagiem ir šis ID - jūsu repozitorijam. Rediģēšana, 2017. gada janvāris: testēšana liecina, ka tagad Git 2.10 ir šāda uzvedība: Ja viņu Git nodrošina tagu ar nosaukumu T, un jums nav taga ar nosaukumu T, un ar T saistītais commit ID ir priekštečs kādam no viņu atzariem, ko pārbauda jūsu git fetch, jūsu Git pievieno T jūsu tagiem ar vai bez --tags. Pievienojot --tags, jūsu Git iegūst visus to tagus, kā arī piespiedu kārtā atjaunina.

Apakšējā līnija

Jums var nākties izmantot git fetch --tags, lai iegūtu to tagus. Ja to tagu nosaukumi ir pretrunā ar jūsu esošajiem tagu nosaukumiem, jums pat var nākties (atkarībā no Git versijas) izdzēst (vai pārdēvēt) dažus no jūsu tagiem un pēc tam palaist git fetch --tags, lai iegūtu viņu tagus. Tā kā tagiem - atšķirībā no attālinātajiem atzariem - nav automātiskas pārdēvēšanas, jūsu tagu nosaukumiem ir jāsakrīt ar to tagu nosaukumiem, tāpēc var rasties konfliktsituācijas. Tomēr visbiežāk parastos gadījumos vienkāršs git fetch paveiks savu darbu, pārnesot viņu veiktās izmaiņas un tām atbilstošās birkas, un, tā kā viņi - lai kas tie būtu - atzīmēs izmaiņas brīdī, kad tās publicēs, jūs sekosiet līdzi viņu birkām. Ja jūs neizveidosiet savus tagus, nedz arī sajauksiet viņu repozitoriju ar citiem repozitorijiem (izmantojot vairākus attālinātos repozitorijus), jums nebūs arī nekādu tagu nosaukumu kolīziju, tāpēc jums nebūs jātraucas ar tagu dzēšanu vai pārdēvēšanu, lai iegūtu viņu tagus.

Ja jums ir nepieciešami kvalificēti nosaukumi

Iepriekš minēju, ka refs/ varat izlaist gandrīz vienmēr, bet refs/heads/ un refs/tags/ un tā tālāk - gandrīz vienmēr. Bet kad *nevarat? Pilnīga (vai gandrīz pilnīga) atbilde ir atrodama gitrevisions dokumentācijā. Git atrisinās nosaukumu uz commit ID, izmantojot sešu soļu secību, kas norādīta šajā saitē. Interesanti, ka tagi aizstāj filiāles: ja ir tags xyzzy un filiāle xyzzy, un tie norāda uz dažādām nodevām, tad:

git rev-parse xyzzy

parādīs ID, uz kuru norāda birka. Tomēr - un tas ir tas, kā trūkst gitrevisions - git checkout dod priekšroku zaru nosaukumiem, tāpēc git checkout xyzzy ievietos jūs atzarā, neņemot vērā tagu. Neskaidrību gadījumā jūs gandrīz vienmēr varat uzrakstīt atzarojuma nosaukumu, izmantojot tā pilnu nosaukumu, refs/heads/xyzzy vai refs/tags/xyzzy. (Ņemiet vērā, ka tas darbojas ar git checkout, bet, iespējams, negaidītā veidā: git checkout refs/heads/xyzzy izraisa atdalītu-galvas pārbaudi, nevis filiāles pārbaudi. Tāpēc jums vienkārši jāņem vērā, ka git checkout vispirms kā filiāles nosaukumu izmantos saīsināto nosaukumu: tā jūs pārbaudīsiet filiāli xyzzy pat tad, ja pastāv birka xyzzy. Ja vēlaties pārbaudīt birku, varat izmantot refs/tags/xyzzy.) Tā kā (kā atzīmē gitrevisions) Git mēģinās refs/name, jūs varat arī vienkārši rakstīt tags/xyzzy, lai identificētu nodošanu ar birku xyzzy. (Ja kādam ir izdevies ierakstīt derīgu atsauci ar nosaukumu xyzzy datubāzē $GIT_DIR, tā tiks atrisināta kā $GIT_DIR/xyzzy. Bet parasti $GIT_DIR ir jābūt tikai dažādiem *HEAD nosaukumiem.)

1Labi, labi, "ne tikai tāpēc, lai būtu pedantisks". :-) 2Daži teiktu "ļoti nelietderīgi", un es, patiesībā, tam piekrītu. 3Būtībā git fetch un visa tālvadības un refspecs koncepcija bija nedaudz novēlots papildinājums Git, kas radās aptuveni Git 1.5 laikā. Pirms tam bija tikai daži ad-hoc īpaši gadījumi, un viens no tiem bija tagu iegūšana, tāpēc tas tika iekļauts ar īpašu kodu. 4Ja tas palīdz, domājiet par attālināto Git kā par flasher slengā.

Lai iegūtu konkrētu tag kodu, mēģiniet izveidot jaunu filiāli, pievienojiet tajā tag kodu. Es to izdarīju ar komandu: $git checkout -b newBranchName tagName.