Trudno zrozumieć git-fetch

Felipec odpowiedział na większość pytań w swojej odpowiedzi .

Kilka pozostałych (większość zaczerpnięta z Git fetch strony Man; która jest niestety trochę przestarzała w niektórych miejscach):

• Jeśli remote-tracking branch (branch, który śledzi jakąś gałąź w jakimś zdalnym repozytorium) nie istnieje, zostanie utworzona.

• Gałąź, do której pobierasz (<dst> w [+]<src>:<dst>) nie musi znajdować się w remotes/<remote>/ przestrzeń nazw. Na przykład dla repozytoriów mirroringowych (git clone --mirror) refspec wynosi 1 do 1. W dawnych czasach przed oddzielnym układem pilotów (przed remotes/<remote>/ przestrzenią nazw dla zdalnego śledzenia refów) Master branch był pobierany do gałęzi o nazwie origin. Nawet obecnie tagi są pobierane bezpośrednio do tags/ przestrzeni nazw w sposób odzwierciedlający.

• Jeśli gałąź do której pobierasz (prawa strona refspec <src>:<dst> istnieje, Git sprawdzi czy pobieranie spowoduje szybkie przewinięcie do przodu, tzn. jeśli bieżący stan w <dst> jest przodkiem stanu w <src> w danym zdalnym repozytorium. Jeśli nie, a ty nie używasz -f/--force opcja git-fetch lub prefiks refspec z '+' (użyj +<src>:<dst> refspec) fetch odmówi aktualizacji tej gałęzi.

• git fetch origin master jest odpowiednikiem git fetch origin master:, a nie git fetch origin master:master; przechowuje pobraną wartość master branch (zdalnego origin ) W FETCH_HEAD , a nie w master branch lub remote-tracking remotes/origin/master branch. Po nim może następować git merge FETCH_HEAD. Zazwyczaj nie jest używany bezpośrednio, ale jako część jednorazowego ściągania bez ustawiania gałęzi zdalnego śledzenia: git pull <URL> <branch>.

• +refs/heads/*:refs/remotes/origin/* jako wartość dla remote.pochodzenie.fetch zmienna konfiguracyjna oznacza, że każda gałąź (ref w refs/heads/ przestrzeni nazw) w zdalnym origin jest pobierana do odpowiednio nazwanej gałęzi zdalnego śledzenia w refs/remotes/origin/ przestrzeni nazw, np. master gałąź w origin (tzn. refs/heads/master ref) będzie pobierana do origin / master remote-tracking branch (czyli refs/remotes/origin/master ref). Przedrostek " + " oznacza, że fetch zakończy się sukcesem nawet w przypadku, gdy branch on remote zostanie ponownie skompresowany, lub przewinięty (zresetowany do jakiegoś stanu w przeszłości) lub w inny sposób zmieniony.

Sidenote: prawdopodobnie chciałbyś użyć wyższego poziomu polecenia git remote do zarządzania zdalnymi repozytoriami i uzyskiwania aktualizacji.

Zauważ, że główny opiekun Git dodał teraz (Git 2.1, sierpień 2014) to wyjaśnienie dla git fetch:
(Zobacz commit fcb14b0 by Junio C Hamano (gitster):

SKONFIGUROWANE GAŁĘZIE ZDALNEGO ŚLEDZENIA

Często wchodzi się w interakcję z tym samym zdalnym repozytorium, regularnie i wielokrotnie pobierając z niego. W celu śledzenia postępu prac takiego zdalnego repozytorium, git fetch pozwala na konfigurację konfiguracji remote.<repository>.fetch zmienne.

Typowo taka zmienna może wyglądać tak:

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*

Ta konfiguracja jest używana na dwa sposoby:

• Gdy git fetch jest uruchamiane bez określenia, jakie gałęzie i/lub znaczniki należy pobrać w wierszu poleceń, np. git fetch origin lub git fetch, remote.<repository>.fetch wartości są używane jako refspecs - - - określają, które refs pobrać i które lokalne refs zaktualizować.
  Powyższy przykład pobierze wszystkie gałęzie, które istnieją w origin (tj. dowolny ref to odpowiada lewej stronie wartości, refs/heads/*) i aktualizuje odpowiednie gałęzie zdalnego śledzenia w hierarchii refs/remotes/origin/*.

• Kiedy git fetch jest uruchamiane z jawnymi gałęziami i / lub znacznikami do pobrania z linii poleceń, np. git fetch origin master, <refspec>S podane w linii poleceń określają, co ma być pobrane (np. master W przykładzie, który jest krótką ręką dla master:, co z kolei oznacza "fetch the' master ' branch, ale nie mówię wprost, jaką gałąź do zdalnego śledzenia aktualizacja z linii poleceń"), a przykładowe polecenie pobierze tylko gałąź 'master'.
  Wartości remote.<repository>.fetch określają, która gałąź zdalnego śledzenia, jeśli istnieje, jest aktualizowana.
  Gdy są używane w ten sposób, wartości remote.<repository>.fetch nie mają żadnego wpływu na decyzję co zostanie pobrane (tzn. wartości nie są używane jako refspecs, gdy wiersz poleceń wyświetla refspecs); są one używane tylko do decydowania gdzie refs, które są pobierane są przechowywane przez działanie jako refspecs. mapowanie.

Zauważ również, że z Git 2.5+ (Q2 2015), git merge FETCH_HEAD Może połączyć wiele Gita fetch ' ów.

Zobacz commit d45366e by Junio C Hamano (gitster), 26 Mar 2015.
^{(dodany przez Junio C Hamano -- gitster -- in commit bcd1ecd , 19 maja 2015)}

"git merge FETCH_HEAD" okazało się, że poprzednie" git fetch "może być tworzeniem połączenia ośmiornicy, tzn. nagrywaniem wielu gałęzi, które nie są oznaczone jako "not-for-merge";
to pozwala nam stracić wywołanie starego stylu "git merge <msg> HEAD $commits... "w implementacji skryptu" git pull"; składnia starego stylu może być teraz przestarzała.

The git merge doc teraz wspomnij:

Kiedy FETCH_HEAD (i żaden inny commit) jest określony, gałęzie zapisane w pliku .git/FETCH_HEAD przez poprzednie wywołaniegit fetch do scalania są scalane do bieżącej gałęzi .

merge: drop 'git merge <message> HEAD <commit>' składnia

Przestań wspierać składnię " git merge <message> HEAD <commit>", która ma został wycofany od października 2007 r. i wysyła komunikat ostrzegawczy o wycofaniu od wersji 2.5.0.

Oznacza to, że komunikat ostrzegawczy w starym stylu" 'git merge <msg> HEAD <commit>' is deprecated. " już nie istnieje.