(ta odpowiedź zajęła trochę czasu, aby napisać, i odpowiedź codewizarda jest poprawna w celu i istocie, ale nie do końca kompletna, więc i tak to opublikuję.)

Nie ma czegoś takiego jak "zdalny znacznik Git". Są tylko "tagi". Zaznaczam to wszystko, żeby nie być pedantycznym,¹ ale ponieważ istnieje wiele zamieszania co do tego z przypadkowymi użytkownikami Git, a dokumentacja Git nie jest zbyt pomocna² za początkujących. (Nie jest jasne, czy zamieszanie przychodzi z powodu złej dokumentacji, albo z powodu złej dokumentacji, ponieważ jest to z natury nieco mylące, czy co.)

Istnieją "odległe gałęzie", właściwie nazywane "gałęziami zdalnego śledzenia", ale warto zauważyć, że są to w rzeczywistości lokalne podmioty. Nie ma jednak znaczników zdalnych (chyba, że je wymyślisz). Istnieją tylko lokalne tagi, więc musisz uzyskać tag lokalnie, aby go użyć.

Ogólna forma nazw dla konkretne commity-które Git wywołuje reference - to dowolny łańcuch zaczynający się od refs/. Łańcuch zaczynający się na refs/heads/ nazywa gałąź; łańcuch zaczynający się na refs/remotes/ nazywa gałąź zdalnego śledzenia; a łańcuch zaczynający się na refs/tags/ nazywa znacznik. Nazwa refs/stash jest odniesieniem do skrytki (używanym przez git stash; zwróć uwagę na brak końcowego ukośnika).

Istnieją niezwykłe nazwy przypadków specjalnych, które nie zaczynają się od refs/: HEAD, ORIG_HEAD, MERGE_HEAD, i CHERRY_PICK_HEAD w szczególności wszystkie są również nazwy to może odnosić się do konkretnych commitów (choć HEAD zwykle zawiera nazwę gałęzi, tzn. zawiera ref: refs/heads/branch). Ogólnie rzecz biorąc, odniesienia zaczynają się od refs/.

Jedną z rzeczy, które Git robi, aby to zamieszać, jest to, że pozwala Ci pominąć refs/, a często słowo po refs/. Na przykład, możesz pominąć refs/heads/ lub refs/tags/ w odniesieniu do lokalnej gałęzi lub tagu-a w rzeczywistości musisz pominąć podczas sprawdzania lokalnej gałęzi! Możesz to zrobić, gdy wynik jest jednoznaczne, lub-jak właśnie zauważyliśmy-kiedy trzeba to zrobić (dla git checkout branch).

To prawda, że referencje istnieją nie tylko w twoim własnym repozytorium, ale także w zdalnych repozytoriach. Jednakże, Git daje dostęp do zdalnego repozytorium tylko w bardzo specyficznych momentach: mianowicie podczas operacji fetch i push. Możesz również użyć git ls-remote lub git remote show, aby je zobaczyć, ale fetch i push są bardziej interesującymi punktami kontaktu.

Refspecs

Podczas fetch i push, Git używa łańcuchów, które wywołuje refspecs do przesyłania referencji pomiędzy lokalnym i zdalnym repozytorium. Tak więc, w tych czasach, za pośrednictwem refspecs, dwa repozytoria Git mogą się ze sobą zsynchronizować. Po zsynchronizowaniu nazw możesz użyć tej samej nazwy, której używa ktoś z pilotem. Na fetch jest jednak jakaś specjalna magia, która wpływa zarówno na nazwy gałęzi, jak i znaczników.

Powinieneś myśleć o git fetch jako o kierowaniu Twojego Gita do wywołania (a może text-message) kolejny Git- "remote" - i porozmawiaj z nim. Na początku tej rozmowy pilot wymienia wszystkie swoje odniesienia: wszystko w refs/heads/ i wszystko w refs/tags/, wraz z innymi odniesieniami, które posiada. Twój Git skanuje je i (bazując na zwykłym fetch refspec) zmienia nazwę ich gałęzi.

Przyjrzyjmy się normalnemu refspec dla pilota o nazwie origin:

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

Ten refspec instruuje Twojego Gita, aby wziął każdą nazwę pasującą refs/heads/* - tzn. każda gałąź na zdalnym - i zmienić jej nazwę na refs/remotes/origin/*, tzn. zachować dopasowaną część bez zmian, zmieniając nazwę gałęzi (refs/heads/) na zdalnie śledzącą nazwę gałęzi (refs/remotes/, w szczególności refs/remotes/origin/).

To właśniepoprzez ten refspec gałęzie origin stają się gałęziami zdalnego śledzenia dla zdalnego origin. Branch name staje się Remote-tracking branch name, z dołączoną nazwą remote, w tym przypadku origin. Znak plus + Z przodu refspec ustawia flagę "force", tzn. twoja gałąź zdalnego śledzenia zostanie zaktualizowana tak, aby pasowała do nazwy gałęzi zdalnego śledzenia, niezależnie od tego, czego potrzeba, aby ją dopasować. (Bez +, aktualizacje gałęzi są ograniczone do" przewijania do przodu " zmian, a aktualizacje tagów są po prostu ignorowane od wersji 1.8.2 Git-wcześniej te same reguły przewijania do przodu.)

Tagi

Ale co z tagami? Nie ma dla nich refspec-przynajmniej nie domyślnie. Możesz ustawić jeden, w którym to przypadku postać refspec zależy od ciebie; lub możesz uruchomić git fetch --tags. Użycie --tags ma efekt dodania refs/tags/*:refs/tags/* do refspec, tzn. przenosi wszystkie znaczniki (, ale nie aktualizuje twojego znacznika jeśli masz już znacznik o tej nazwie, niezależnie od tego, co mówi znacznik pilota Edit, Styczeń 2017: Od wersji Git 2.10, testing pokazuje, że --tags siłą aktualizuje Twoje znaczniki ze znaczników pilota, tak jakby refspec czytał +refs/tags/*:refs/tags/*; może to być różnica w zachowaniu w stosunku do wcześniejszej wersji Git).

Zauważ, że tutaj nie ma zmiany nazwy: jeśli remote origin ma tag xyzzy, a ty nie, a Ty git fetch origin "refs/tags/*:refs/tags/*", dostajesz refs/tags/xyzzy dodane do repozytorium(wskazując na ten sam commit co na remote). Jeśli używasz +refs/tags/*:refs/tags/*, to Twój tag xyzzy, jeśli go posiadasz, jest zastąpiony przez ten z origin. Oznacza to, że znacznik + force na refspec oznacza "zamień wartość referencji na tę, którą mój Git dostaje z ich Gita".

Tagi Automagic podczas aport

Ze względów historycznych,³ jeśli nie użyjesz ani opcji --tags, ani opcji --no-tags, git fetch podejmie specjalne działania. Pamiętaj, że powiedzieliśmy powyżej, że pilot zaczyna się od wyświetlenia do lokalnego Git wszystkich jego referencji, niezależnie od tego, czy lokalny Git chce je zobaczyć, czy nie.⁴ Twój Git odnotowuje wszystkie znaczniki, które widzi w tym momencie. następnie, gdy zaczyna pobierać obiekty commit, musi obsłużyć to, co pobiera, jeśli jeden z tych commitów ma taki sam ID jak każdy z tych tagów, git doda ten tag - lub te tagi, jeśli wiele tagów ma ten ID-do twojego repozytorium.

Edit, Styczeń 2017: testowanie pokazuje, że zachowanie w Git 2.10 jest teraz następujące: jeśli ich Git dostarcza znacznik o nazwie T, i nie masz znacznika o nazwie T, i identyfikator commitu skojarzony z T jest przodkiem jednej z ich gałęzi, którą twój {31]} bada, Twój Git dodaje T do Twoich tagów z lub bez --tags. Dodanie --tags spowoduje, że Twój Git uzyska wszystkie ich znaczniki, a także wymusi aktualizację.

Bottom line

Być może będziesz musiał użyć git fetch --tags, aby zdobyć ich znaczniki. Jeśli ich nazwy znaczników są sprzeczne z istniejącymi nazwami, możesz {107]} (w zależności od wersji Gita) nawet usunąć (lub zmienić nazwę) niektóre z tagów, a następnie uruchomić git fetch --tags, aby uzyskać ich znaczniki. Ponieważ znaczniki-w przeciwieństwie do zdalnych gałęzi-nie mają automatycznej zmiany nazwy, nazwy znaczników muszą być zgodne z ich nazwami, dlatego mogą występować problemy z konfliktami.

W w większości {107]} normalnych przypadkach, proste git fetch wykona zadanie, wprowadzając commity i pasujące znaczniki, a ponieważ oni-kimkolwiek są - będą tagować commity w momencie ich opublikowania, będziesz nadążał za ich znacznikami. Jeśli nie tworzysz własnych tagów ani nie mieszasz ich repozytoriów z innymi repozytoriami (za pomocą wielu pilotów), nie będziesz mieć żadnej nazwy znacznika kolizje albo, więc nie będziesz musiał zamieszać z usuwaniem lub zmienianiem nazw tagów w celu uzyskania ich tagów.

Kiedy potrzebujesz kwalifikowanych nazw

Wspomniałem powyżej, że można pominąć refs/ prawie zawsze, i refs/heads/ i refs/tags/ i tak przez większość czasu. Ale kiedy nie możesz ty?

Pełna (lub prawie kompletna) odpowiedź znajduje się w gitrevisions dokumentacja . Git rozwiąże nazwę z identyfikatorem zatwierdzenia używając sześciostopniowej sekwencji podanej w linku. Co ciekawe, znaczniki zastępują gałęzie: jeśli istnieje znacznik xyzzy i gałąź xyzzy i wskazują na różne commity, to:

git rev-parse xyzzy

Poda ci identyfikator, na który wskazuje znacznik. Jednak-i tego właśnie brakuje w gitrevisions-git checkout preferuje nazwy gałęzi, więc git checkout xyzzy umieści Cię na gałęzi, pomijając tag.

W przypadku niejasności, prawie zawsze można przeliterować nazwę ref używając jego pełnej nazwy, refs/heads/xyzzy lub refs/tags/xyzzy. (Zauważ, że to działa z [74]}, ale w Być może nieoczekiwany sposób: [79]} powoduje checkout z odłączoną głową, a nie checkOut z gałęzią. Dlatego musisz tylko pamiętać, że git checkout będzie używać skróconej nazwy jako nazwy gałęzi jako pierwszej: w ten sposób sprawdzasz gałąź xyzzy, nawet jeśli znacznik xyzzy istnieje. Jeśli chcesz sprawdzić tag, możesz użyć refs/tags/xyzzy.)

Ponieważ (jako gitrevisions uwagi) Git spróbuje refs/name, możesz po prostu napisać tags/xyzzy, aby zidentyfikować commit oznaczony xyzzy. (Jeśli komuś udało się zapisuje poprawne odniesienie o nazwie xyzzy do $GIT_DIR, jednak to rozwiąże się jako $GIT_DIR/xyzzy. Ale zwykle tylko różne nazwy *HEAD powinny być w $GIT_DIR.)

¹OK, OK, "nie tylko być pedantycznym". :-)

²niektórzy powiedzieliby "bardzo Nie-pomocny" , a ja raczej się z tym Zgadzam.

³Ogólnie rzecz biorąc, git fetch, i cała koncepcja pilotów i refspeców, była nieco późnym dodatkiem do Git, dzieje się wokół czas Git 1.5. Wcześniej zdarzały się tylko doraźne przypadki specjalne, a tag-fetching był jednym z nich, więc dostał się za pomocą specjalnego kodu.

⁴jeśli to pomoże, pomyśl o zdalnym Git jako flasher, w slangowym znaczeniu.