Mówiąc prościej, gdybyś miał wskoczyć do samolotu bez połączenia z Internetem ... przed odlotem mógłbyś to zrobić git fetch origin <master>. Pobierałby wszystkie zmiany na twoim komputerze, ale trzymał go oddzielnie od lokalnego obszaru programowania / pracy.
W samolocie możesz wprowadzić zmiany w lokalnym obszarze roboczym, a następnie scalić je z tym, co pobrałeś i rozwiązać wszystkie potencjalne konflikty scalania bez połączenia z Internetem. I chyba że ktoś wprowadzi nowe sprzeczne zmiany w zdalnym repozytorium, to kiedy dotrzesz do miejsca docelowego, zrobisz to git push origin <branch>i pójdziesz po kawę.
Z tego niesamowitego samouczka Atlassian :
Do git fetchpobrania dowodzenia commity, plików i sędziowie ze zdalnego repozytorium w lokalnym repozytorium.
Pobieranie jest tym, co robisz, gdy chcesz zobaczyć, nad czym wszyscy inni pracują. Jest podobny do aktualizacji SVN, ponieważ pozwala zobaczyć postępy w historii centralnej, ale nie zmusza cię do scalenia zmian w repozytorium. Git izoluje pobrane treści od istniejących treści lokalnych , nie ma to absolutnie
żadnego wpływu na lokalne prace programistyczne . Pobrane treści należy jawnie wypisać za pomocą git checkoutpolecenia. Dzięki temu pobieranie jest bezpiecznym sposobem na sprawdzenie zatwierdzeń przed zintegrowaniem ich z lokalnym repozytorium.
Podczas pobierania zawartości z zdalnego repozytorium, git pulli git fetchpolecenia są dostępne, aby wykonać zadanie. Możesz rozważyć
git fetch„bezpieczną” wersję dwóch poleceń. Pobierze zdalną zawartość, ale nie zaktualizuje stanu pracy lokalnego repozytorium, pozostawiając bieżącą pracę nienaruszoną. git pulljest bardziej agresywną alternatywą, pobierze zdalną zawartość dla aktywnego oddziału lokalnego i natychmiast uruchomi się, git mergeaby utworzyć zatwierdzenie scalania dla nowej zdalnej treści. Jeśli oczekujesz zmian, spowoduje to konflikty i rozpocznie proces rozwiązywania konfliktów scalania.
Z git pull:
- Nie dostajesz żadnej izolacji.
- Wpływa na twój rozwój lokalny.
- Nie musi być jawnie wypisany. Ponieważ domyślnie robi to
git merge.
- Zasadniczo NIE jest bezpieczny. To jest agresywne.
- W przeciwieństwie do tego,
git fetchgdzie wpływa to tylko na ciebie .git/refs/remotes, git pull wpłynie zarówno na ciebie, jak .git/refs/remotes i na .git/refs/heads/
Hmmm ... więc jeśli nie aktualizuję kopii roboczej git fetch, to gdzie wprowadzam zmiany? Gdzie Git Fetch przechowuje nowe zatwierdzenia?
Świetne pytanie. Umieszcza go gdzieś w izolacji od kopii roboczej. Ale znowu gdzie? Dowiedzmy Się.
W katalogu projektu (tj. Tam, gdzie wykonujesz gitpolecenia):
ls. Spowoduje to wyświetlenie plików i katalogów. Nic fajnego, wiem.
Teraz zrób ls -a. To pokaże dot plików , czyli plików rozpoczynające się od .Ciebie będzie mógł zobaczyć katalog o nazwie: .git.
- Zrobić
cd .git. To oczywiście zmieni twój katalog.
- Teraz zaczyna się zabawa; zrobić
ls. Zobaczysz listę katalogów. Szukamy refs. Zrobić cd refs.
- Ciekawie jest zobaczyć, co znajduje się we wszystkich katalogach, ale skupmy się na dwóch z nich.
headsa remotes. Użyj, cdaby sprawdzić również w nich.
- Każda
git fetch czynność spowoduje aktualizację elementów w /.git/refs/remoteskatalogu. Nie zaktualizuje niczego w /.git/refs/headskatalogu.
- Każdy
git pull najpierw zrobi git fetch, zaktualizuje elementy w /.git/refs/remoteskatalogu, a następnie połączy się z lokalnym, a następnie zmieni nagłówek w /.git/refs/headskatalogu.
Bardzo dobrą powiązaną odpowiedź można również znaleźć w temacie Gdzie znajduje się „git fetch”? .
Poszukaj też „Notacji ukośnika” w poście o konwencjach nazewnictwa gałęzi Git . Pomaga ci lepiej zrozumieć, w jaki sposób Git umieszcza rzeczy w różnych katalogach.
Aby zobaczyć rzeczywistą różnicę
Po prostu zrób:
git fetch origin master
git checkout master
Jeśli zdalny moduł główny został zaktualizowany, pojawi się następujący komunikat:
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
Jeśli tego nie zrobiłeś fetchi właśnie to zrobiłeś, git checkout masterlokalny git nie wiedziałby, że dodano 2 zatwierdzenia. I powiedziałoby to po prostu:
Already on 'master'
Your branch is up to date with 'origin/master'.
Ale to jest przestarzałe i niepoprawne. To dlatego, że git przekaże ci informacje zwrotne wyłącznie na podstawie tego, co wie. Nie jest świadomy nowych zobowiązań, których jeszcze nie rozebrał ...
Czy jest jakiś sposób, aby zobaczyć nowe zmiany wprowadzone zdalnie podczas lokalnej pracy w oddziale?
Niektóre IDE (np. Xcode) są super inteligentne i wykorzystują wynik a git fetchi mogą zawierać adnotacje do linii kodu, które zostały zmienione w zdalnej gałęzi twojego obecnego oddziału. Jeśli linia ta została zmieniona zarówno przez zmiany lokalne, jak i gałąź zdalną, wówczas linia ta zostanie opatrzona adnotacjami na czerwono. To nie jest konflikt scalania. Jest to potencjalny konflikt scalania. Jest to headsup, którego możesz użyć do rozwiązania przyszłego konfliktu scalania przed zrobieniem go git pullze zdalnej gałęzi.
Zabawna wskazówka:
Jeśli pobrałeś zdalną gałąź, np. Zrobiłeś:
git fetch origin feature/123
To przejdzie do twojego katalogu pilotów. Nadal nie jest dostępny dla twojego lokalnego katalogu. Upraszcza to jednak dokonywanie płatności do tej zdalnej gałęzi przez DWIM (Rób co mam na myśli):
git checkout feature/123
nie musisz już robić:
git checkout -b feature/123 origin/feature/123
Więcej na ten temat przeczytasz tutaj
