kad es izrakstīšanās attālā git tag izmantot komandu, piemēram, šādu:
git checkout -b local_branch_name origin/remote_tag_name
Es saņēmu šādu kļūdu:
error: pathspec `origin/remote_tag_name` did not match any file(s) known to git.
Es varu atrast remote_tag_name, kad izmantoju komandu git tag.
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ē.
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/<tag_name> -b <branch_name>
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
# list all tags
git tag
# list all tags with given pattern ex: v-
git tag --list 'v-*'
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.
# delete any given tag
git tag -d <tag name>
# Don't forget to remove the deleted tag form the server with push tags
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/<tag> -b <branch>
Variants 2:
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 <url> --branch=<tag_name>
git clone --branch=
--zacirknis
var ņemt arī tagus un atdalīt HEAD pie šīs nodošanas iegūtajā repozitorijā..
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:
Sākot ar Git 2.4, to var iestatīt, izmantojot konfigurāciju
git config --global push.followTags true
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.
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).
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".
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.
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.
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
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ā.