Pytanie Jaka jest różnica między "git pull" i "git fetch"?


Uwaga dla moderatora: Biorąc pod uwagę, że to pytanie już miało miejsce sześćdziesiąt cztery odpowiedzi wysłana do niego, zastanów się, czy jesteś wnosząc coś nowego przed opublikowaniem kolejnego.

Jakie są różnice między git pull i git fetch?


10149
2017-11-15 09:51


pochodzenie


Znalazłem ten dobrze napisany artykuł na temat git fetch i git pull, które warto przeczytać: longair.net/blog/2009/04/16/git-fetch-and-merge - Marcos Oliveira
Nasze alternatywne podejście stało się git fetch; git reset --hard origin/master w ramach naszego przepływu pracy. Usuwa lokalne zmiany, utrzymuje cię na bieżąco z mistrzem, ale zapewnia, że ​​nie tylko wprowadzasz nowe zmiany na bieżąco, jeśli chodzi o bieżące zmiany i wprowadzasz bałagan. Używaliśmy go przez jakiś czas i zasadniczo czujemy się o wiele bezpieczniej w praktyce. Tylko pamiętaj, aby najpierw dodać / zatwierdzić / ukryć wszystkie prace w toku! - Michael Durrant
Upewnij się, że umiesz poprawnie korzystać ze schowka git. Jeśli pytasz o "pull" i "fetch", być może "ukrywanie" będzie również wymagało wyjaśnienia ... - Henry Heleine
Wielu ludzi pochodzących z Mercurial używa "git pull", myśląc, że jest odpowiednikiem "hg pull". Który nie jest. Odpowiednikiem Git dla "hg pull" jest "git fetch". - Serge Shultz
Polecenie git fetch pobiera zaktualizowany kod z odgałęzieniem, a także pobiera nowo dodane gałęzie w lokalnym poleceniu git pull pobiera tylko zaktualizowany kod tylko bieżącego oddziału - Kartik Patel


Odpowiedzi:


Najprościej, git pull robi a git fetch następnie a git merge.

Możesz zrobić git fetch w dowolnym momencie, aby zaktualizować oddziały zdalnego śledzenia w kategorii refs/remotes/<remote>/.

Ta operacja nigdy nie zmienia żadnego z twoich lokalnych oddziałów w ramach refs/headsi można to zrobić bez zmiany kopii roboczej. Słyszałem nawet o ludziach, którzy biegają git fetch okresowo w pracy cron w tle (chociaż nie polecałbym tego).

ZA git pull to jest to, co możesz zrobić, aby zaktualizować lokalną gałąź za pomocą wersji zdalnej, a także aktualizować inne gałęzie zdalnego śledzenia.

Dokumentacja Git: git pull


8470
2017-11-15 09:52



"A" git pull "jest tym, co zrobiłbyś, aby uaktualnić swoje repozytorium" <- czy aktualizacja repozytorium już nie została wykonana przez pobranie? czy nie oznacza to, że aktualizuje swoje oddziały lokalne w odległych oddziałach? Do scalenia: Łączy odległe gałęzie z lokalnymi kopiami tych oddziałów, lub co dokładnie tu się łączy? - Albert
@Albert: Tak, to dziwne słowo. git pull zawsze scalą się w obecny oddział. Wybierasz gałąź, którą chcesz ciągnąć odi wciąga go do bieżącej gałęzi. The od gałąź może być lokalna lub zdalna; może to być nawet oddział zdalny, który nie jest zarejestrowany git remote (co oznacza, że ​​przekazujesz URL do git pull wiersz poleceń). - intuited
@espertus: Nie. Pchanie nigdy automatycznie nie powoduje scalenia. Użytkownik powinien ciągnąć, rozwiązywać konflikty lokalnie, następnie wróć do pilota. - Greg Hewgill
Jeśli jestem w /home/alice/ i robić git fetch /home/bob, jakie parametry powinienem przejść do następnego git merge ? - ripper234
Uwaga dla osób uczących się Git: pull nie może być faktycznie emulowany przez a fetch plus a merge. Właśnie przyniosłem zmianę, w której zmienia się tylko wskaźnik gałęzi zdalnej, i merge odmawia zrobienia czegokolwiek. pull, z drugiej strony, szybko przewija moją gałąź śledzenia. - Roman Starkov


  • Kiedy używasz pullGit próbuje automatycznie wykonać twoją pracę za ciebie. Jest to zależne od kontekstu, więc Git połączy wszystkie wyciągnięte zatwierdzenia z oddziałem, w którym aktualnie pracujesz. pull  automatycznie łączy zatwierdzenia bez uprzedniego ich przeglądania. Jeśli nie ściśle zarządzasz swoimi oddziałami, możesz natknąć się na częste konflikty.

  • Kiedy ty fetch, Git zbiera wszystkie zatwierdzenia z gałęzi docelowej, które nie istnieją w twojej obecnej gałęzi i przechowuje je w lokalnym repozytorium. Jednak, nie łączy ich z bieżącym oddziałem. Jest to szczególnie użyteczne, jeśli chcesz mieć aktualne repozytorium, ale pracujesz nad czymś, co może się zepsuć, jeśli zaktualizujesz swoje pliki. Aby zintegrować zatwierdzenia do gałęzi głównej, używasz merge.


1850
2017-08-18 08:53



Zgoda, świetny komentarz. Dlatego nienawidzę git pull. Kiedy byłoby sensowne, aby narzędzie do wprowadzania zmian wprowadzało dla ciebie zmiany kodu? A czy to nie jest to, co robi łączenie dwóch plików? Co jeśli te dwie zmiany są fizycznie oddzielone w pliku, ale LOGICALLY jest sprzeczne? - Lee Dixon
@ Krótkie wprowadzenie do e-maila, git fetch aktualizuje tylko twoje .git/ katalog (AKA: lokalne repozytorium) i nic na zewnątrz .git/ (AKA: drzewo robocze). Nie zmienia twoich lokalnych oddziałów i nie dotyka master zarówno. Dotyka remotes/origin/master choć (patrz git branch -avv). Jeśli masz więcej pilotów, spróbuj git remote update. To jest git fetch dla wszystkich pilotów w jednym poleceniu. - Tino
@Tino yours jest naprawdę najważniejszym punktem. Ludzie mogą nie wiedzieć, że "zdalne" gałęzie są w rzeczywistości przechowywane jako grupa skrótów .git/refs/remotes/origin/. - Chris
Podczas pobierania Git zbiera wszystkie zatwierdzenia z gałęzi docelowej, które nie istnieją w bieżącej gałęzi i przechowuje je w lokalnym repozytorium - jak mogę zobaczyć, co zostało dostarczone z pilota i jak scalić go z lokalnymi oddziałami? - アレックス
@Tino To, czego wciąż nie rozumiem, to ... o co ci chodzi? Po co używać pobierania, jeśli tylko aktualizuje .git? Jaka jest zamierzona korzyść i co powinienem zrobić po tym? - BadHorsie


Ważne jest, aby kontrastować filozofię projektowania git z filozofią bardziej tradycyjnego narzędzia kontroli źródła, takiego jak SVN.

Subversion został zaprojektowany i zbudowany przy użyciu modelu klient / serwer. Istnieje jedno repozytorium, które jest serwerem, a kilku klientów może pobrać kod z serwera, pracować nad nim, a następnie przekazać go z powrotem do serwera. Założeniem jest, że klient zawsze może skontaktować się z serwerem, gdy musi wykonać operację.

Git został zaprojektowany do obsługi bardziej rozproszonego modelu bez potrzeby centralnego repozytorium (choć z pewnością możesz go użyć, jeśli chcesz). Również git został zaprojektowany tak, że klient i "serwer" nie muszą być w tym samym czasie online. Git został zaprojektowany w taki sposób, aby ludzie na niewiarygodnym łączu mogli wymieniać kod nawet za pomocą poczty e-mail. Możliwe jest działanie całkowicie rozłączone i nagrywanie płyty CD w celu wymiany kodu poprzez git.

W celu wsparcia tego modelu git utrzymuje lokalne repozytorium z twoim kodem, a także dodatkowe lokalne repozytorium, które odzwierciedla stan zdalnego repozytorium. Przechowując lokalnie kopię zdalnego repozytorium, git może znaleźć potrzebne zmiany, nawet jeśli nie można uzyskać zdalnego repozytorium. Później, kiedy będziesz musiał wysłać zmiany komuś innemu, git może przesłać je jako zestaw zmian z czasu znanego dla zdalnego repozytorium.

  • git fetchjest poleceniem "zaktualizuj moją lokalną kopię zdalnego repozytorium".

  • git pull mówi "przynieś zmiany w odległym repozytorium, w którym przechowuję swój własny kod."

Zwykle git pull robi to, wykonując a git fetch aby zaktualizować lokalną kopię zdalnego repozytorium, a następnie scalić zmiany z własnym repozytorium kodu i ewentualnie z kopią roboczą.

Na wynos należy pamiętać, że często jest co najmniej trzy kopie projektu na twojej stacji roboczej. Jedna kopia to własne repozytorium z własną historią commitów. Druga kopia to kopia robocza, w której edytujesz i budujesz. Trzecia kopia jest twoją lokalną "buforowaną" kopią zdalnego repozytorium.


1008
2018-03-31 18:43



Technicznie, lokalne i zdalne repozytoria są naprawdę takie same. W Git repozytorium to DAG zobowiązań wskazujących na swoich rodziców. Oddziały są, z technicznego punktu widzenia, niczym więcej niż znaczącymi nazwiskami commits. Jedyną różnicą między oddziałami lokalnymi i zdalnymi jest to, że zdalne są poprzedzone prefiksem remoteName/  Git od podstaw to bardzo dobra lektura. Kiedy zrozumiesz, jak działa Git - i jest pięknie prosty, naprawdę - wszystko ma sens. - Emil Lundberg
Wielkie dzięki za wyjaśnienie. Do tej pory nie rozumiałem, że Git został zaprojektowany, więc nie musicie mieć centralnego repozytorium. Każdy zawsze mówi "DVCS" przy opisie Gita, ale jako stosunkowo nowy programista, to nic dla mnie nie znaczy. Nigdy nie widziany CVCS, a ja też nigdy nie pracowałem z centalnym repozytorium zdalnym podczas współpracy z innymi (tj. Github), więc do tej pory nie zrozumiałem jeszcze, co sprawiło, że Git jest wyjątkowy. - Brian Peterson
Opierając się na tym, dlaczego nie jest dobrym pomysłem, aby git-fetch z zadaniem cron? Zawsze zachowywanie kopii pilota, z którym pracujesz, na twoim lokalnym komputerze wydaje się być dobrym pomysłem. Właściwie to mam ochotę napisać skrypt, który sprawdzi, czy zaktualizowałem mój pilot w ciągu ostatnich 24 godzin i czy powiązałem go z hakiem udev do połączenia z Internetem. - Brian Peterson
Jednym z powodów, dla których NIE jest dobrym pomysłem na wykonanie zadania cron: często podczas pracy nad nowym biletem lub aktualizacjami do oddziału, chcę zobaczyć, jakie zmiany są pobierane. Jeśli zmiany nie pojawią się w trakcie pobierania, będę bardziej pewny, że zapytam mojego kolegę programistę, "hej czy ty naciskasz?". Mam również poczucie, ile "churn" w repozytorium od ostatniego pobrania. Pomaga to również w określeniu ilości i szybkości zmian, jakie obecnie wprowadzane są w tym repozytorium. - Michael Durrant
@Nabheet Thing jest to, że Git jest zorientowany na treść. Przechowuje dane tylko raz i wskazuje je kilka razy. Dlatego w Git nawet wielokrotne zatwierdzenia na oryginale nie wpływają na wielkość repo wiele, ponieważ większość obiektów jest taka sama. - cst1992


Tutaj jest Obraz Olivera Steele, jak wszystko to pasuje do siebie:

enter image description here

Jeśli istnieje wystarczające zainteresowanie, przypuszczam, że mógłbym zaktualizować obraz, aby go dodać git clone i git merge...


664
2018-06-09 13:30



Zaktualizowany obraz z git clone i git merge byłoby bardzo pomocne! - MEMark
Tak, dodaj git merge - powinno to wyraźnie pokazywać merge nazywany osobno NIE jest tym samym, co wywołanie pull bo pull łączy się tylko ze zdalnym i ignoruje lokalne zatwierdzenia w lokalnym oddziale, które śledzi odbierający oddział zdalny. - JustAMartin
Obraz jest wart tysiąca słów! Czy zaktualizowany obraz jest gotowy do klonowania i scalania danych? Wszelki inny przepływ danych poza tym, co już jest na diagramie? - shikhanshu
@Contango dodaj klonowanie i scalanie. Byłoby pomocne dla początkujących, takich jak ja. - rents
Istnieją dwa diagramy pokazujące klonowanie i scalanie w innych odpowiedziach (poniżej) przez th3sly i thedarkpassenger. - intotecho


Jeden przypadek użycia git fetch jest to, że następujące informacje będą informować o wszelkich zmianach w oddziale zdalnym od czasu ostatniego wyciągnięcia ... abyś mógł sprawdzić przed wykonaniem rzeczywistego pociągnięcia, które może zmienić pliki w bieżącej gałęzi i kopii roboczej.

git fetch
git diff ...origin

428
2018-05-07 19:23



Świetny dodatek! Byłem zdezorientowany kropkami, czyż nie ?: pochodzenie git diff - harm
Dlaczego nie git diff ..origin? - Erik Allik
git diff origin i git diff ..origin wydają się działać, ale nie te dziwne ... rzeczy - Marc
@Compustretch Nie powinno być przestrzeni. git diff ...originjest równa git diff $(git-merge-base HEAD origin) origin (patrz git diff [--options] <commit>...<commit> [--] [<path>…] Sekcja kernel.org/pub/software/scm/git/docs/git-diff.html#_description), który jest inny niż git diff origin; git diff ...origin jest koncepcyjnie zmianami dokonanymi w origin ponieważ obecna gałąź rozgałęziała się origin, podczas git diff origin obejmuje także odwrotność zmian wprowadzonych w bieżącym oddziale, od którego się rozgałęziono origin. - Max Nanasy
żadne z poleceń nie działa dla mnie (w Windowsie), ale git diff origin/master działa, jak wspomniano poniżej - Brian Burns


Kosztowało mnie to trochę, aby zrozumieć, jaka była różnica, ale jest to proste wyjaśnienie. master w twoim localhost jest oddział.

Podczas klonowania repozytorium pobierasz całe repozytorium do lokalnego hosta. Oznacza to, że w tym momencie masz wskaźnik początku / wzorca do HEAD i mistrz wskazujący na to samo HEAD.

kiedy zaczynasz pracę i popełniasz, przesuwasz wskaźnik główny na HEAD + Twoje zatwierdzenia. Ale wskaźnik pochodzenia / wzorca wciąż wskazuje na to, co było, gdy sklonowałeś.

Tak więc różnica będzie taka:

  • Jeśli zrobisz git fetch po prostu pobierze wszystkie zmiany w odległym repozytorium (GitHub) i przesuń wskaźnik początku / wzorca do HEAD. W międzyczasie twój lokalny oddział będzie nadal wskazywał, gdzie się znajduje.
  • Jeśli zrobisz git pull, zrobi to w zasadzie pobranie (jak wyjaśniono wcześniej) i połączenie nowych zmian w gałęzi głównej i przeniesienie wskaźnika do HEAD.

342
2018-05-11 18:37



origin / master jest lokalnym odgałęzieniem będącym KOPIĄ mistrza na początku. Podczas pobierania aktualizuje się lokalny: / origin / master. Kiedy naprawdę głupisz, że wszystko w git jest gałęzią, ma to wiele sensu i jest bardzo skutecznym sposobem utrzymywania różnych zestawów zmian, tworzenia szybkich lokalnych oddziałów, łączenia i reorganizacji i generalnie czerpania korzyści z taniego rozgałęzienia Model. - cam8001
Nadal mylące. myślałem git fetch było dosłowne pobieranie zmian na zdalnym repo do lokalnego repozytorium, ale NIE zezwalajcie na nie - to znaczy, że nadal muszą być dodani / zatwierdzeni do lokalnego repo. - krb686
Fetch pobiera tylko ciągi ze zdalnego / origin (github) do lokalnego pochodzenia. Ale nie łączy się go z rzeczywistymi plikami roboczymi. jeśli wykonasz pull, pobierzesz i scalisz z bieżącymi plikami roboczymi - Gerardo


Czasami pomaga reprezentacja wizualna.

enter image description here


180
2018-01-25 17:28



Myślę, że zdjęcie pokazało, że wpływa również na lokalne repozytorium. To znaczy, Git pull jest kombinacją wpływającą na lokalne repozytorium i kopię roboczą. Obecnie wydaje się, że ma to tylko wpływ na kopię roboczą. - 太極者無極而生
@ 太極 者 無極 而 生 Uzgodnione - ten obraz jest dość mylący, ponieważ sprawia, że ​​wygląda git pull jest skaczący pobranie, które oczywiście jest niedokładne. - forresthopkinsa
@thedarkpassenger Dlaczego nie zaktualizujesz swojego obrazu. Wtedy będzie to najlepsze zdjęcie dla początkujących. ^^ - cmcromance
jaka jest różnica między "Repozytorium lokalnym" a "Kopią roboczą"? Czy nie są oni lokalnymi komputerami? - theITvideos


Krótko

git fetch jest podobne do pull ale się nie łączy. to znaczy pobiera zdalne aktualizacje (refs i objects), ale twój lokalny pozostaje taki sam (tj. origin/master zostaje zaktualizowany, ale master nie zmienia się) .

git pull ściąga się z pilota i natychmiast się łączy.

Jeszcze

git clone klonuje repozytorium.

git rebase zapisuje rzeczy z aktualnej gałęzi, która nie znajduje się w gałęzi źródłowej do obszaru tymczasowego. Twoja gałąź jest teraz taka sama jak przed rozpoczęciem zmian. Więc, git pull -rebase usunie zdalne zmiany, przewinie twój lokalny oddział, odtworzy zmiany u góry twojego aktualnego oddziału jeden po drugim, aż będziesz na bieżąco.

Również, git branch -a pokaże dokładnie, co się dzieje ze wszystkimi oddziałami - lokalnymi i zdalnymi.

Ten wpis na blogu był przydatny:

Różnica między git pull, git fetch i git clone (i git rebase) - Mike Pearce

i okładki git pull, git fetch, git clone i git rebase.

====

AKTUALIZACJA

Pomyślałem, że zaktualizuję to, aby pokazać, jak faktycznie używasz tego w praktyce.

  1. Zaktualizuj lokalne repozytorium z poziomu zdalnego (ale nie scalaj):

    git fetch

  2. Po pobraniu aktualizacji zobaczmy różnice:

    git diff master origin / master

  3. Jeśli jesteś zadowolony z tych aktualizacji, połącz się:

    git pull

Uwagi:

W kroku 2: Aby uzyskać więcej informacji na temat różnic między lokalnymi i zdalnymi sterownikami, zobacz: porównać lokalny oddział git z oddziałem zdalnym?

W kroku 3: Prawdopodobnie jest to dokładniejsze (na przykład w przypadku szybko zmieniającego się repozytorium), aby zrobić git rebase origin tutaj. Zobacz komentarz @Justin Ohms w innej odpowiedzi.

Zobacz też: http://longair.net/blog/2009/04/16/git-fetch-and-merge/ 


166
2018-04-13 17:31



Dla mnie brzmi to tak, jakby ktoś chciał, aby lokalny kod odzwierciedlał "wskazówkę", powinien ich użyć git clone. Napisałem końcówkę w cudzysłowach, ponieważ zakładam, że oznaczałoby to, co to jest mistrz i co ktoś "ściągnie jako zip" z github.com - Chris K
co jeśli nie jesteś zadowolony ze zmian po pobraniu? co zrobic nastepnie? - Kugutsumen
Twój akapit na temat rebase był tym, czego szukałem. Cały pomysł o wyzerowaniu wszystkiego, aktualizowaniu z pilota powtarzanie zmian w stosunku do poprzednich zatwierdzeń co miało miejsce podczas pracy. Idealne wyjaśnienie przy założeniu, że jest poprawne. ;) - coblr


git-pull - pobieranie i scalanie z innym repozytorium lub lokalnym oddziałem
STRESZCZENIE

git pull ...
OPIS

Uruchamia git-fetch z podanymi parametrami i wywołuje git-merge, aby scalić
odzyskała głowę (głowy) w bieżącej gałęzi. Z -rebase, wywołuje git-rebase
zamiast git-merge.

Zauważ, że możesz użyć. (bieżący katalog) jako <repozytorium> do ściągnięcia
z lokalnego repozytorium - jest to przydatne przy łączeniu lokalnych oddziałów
w bieżącym oddziale.

Zauważ także, że opcje mają na celu samo git-pull i leżące u podstaw git-merge
należy podać przed opcjami przeznaczonymi do pobierania git.

Wyciągnąłbyś, gdybyś chciał połączyć te historie, przyniosłbyś, gdybyś chciał "kodeksu", ponieważ niektóre osoby opisują tutaj jakieś artykuły.


156
2017-11-15 09:52



Bardzo interesujące, ale tak naprawdę nie widzę przypadku użycia, w którym chcesz "tylko kod". Et, co dzieje się z kodem podczas pobierania? Czy to jest wymazane? Co się dzieje ze zdalnymi zmianami? Jak trafia do twojego repo bez usuwania kodu, jeśli się nie połączysz? - e-satis
@ e-satis: gałąź zdalna jest również przechowywana lokalnie na twoim komputerze. Więc kiedy to zrobisz git fetch pobiera zmiany z repozytorium i aktualizuje lokalny oddział zdalny. Nie ma wpływu na lokalny oddział, który śledzi lokalny oddział zdalny, więc nie ma wpływu na kopię roboczą. Teraz, kiedy robisz mergeScalone zmiany zostaną scalone z lokalnym oddziałem. - jeffreyveon
Prosty przypadek użycia dla polecenia pobierania: wykonywanie czasochłonnych operacji związanych z ostatnimi zatwierdzeniami innych osób, takich jak scalanie lub przegląd kodu, uzyskiwanie dostępu tylko do aktualnego lokalnego repozytorium bez wymagań łączności sieciowej, ponieważ poprzednio używałeś pobierania do pobrania wszystko, czego potrzebujesz szybko (np. gdy odwiedzasz innego programistę i jesteś podłączony do sieci innego repozytorium). Komenda "pull" pobierze te same zatwierdzenia, ale scalenie, które wykonuje, może być niepożądane. - Lorenzo Gatti


Możesz pobrać ze zdalnego repozytorium, zobaczyć różnice, a następnie wyciągnąć lub scalić.

To jest przykład dla zdalnego repozytorium o nazwie origin i dzwonił oddział master śledzenie zdalnego oddziału origin/master:

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

143
2018-03-21 11:07



Prawdopodobnie chcesz pominąć przyciąganie i po prostu zrobić "początek git rebase" jako ostatni krok od czasu, gdy już pobrałeś zmiany. Powodem jest to, że ktoś mógł pchnąć zmiany w czasie, który upłynął od czasu pobrania, a te nie byłyby w trakcie pobierania, na którym przeprowadzono analizę różnic. - Justin Ohms


Krótka i łatwa odpowiedź jest taka git pull jest po prostu git fetch śledzony przez git merge.

Bardzo ważne jest, aby to zauważyć git pull będzie automatycznie scalać, czy ci się to podoba, czy nie. Mogłoby to oczywiście doprowadzić do konfliktów scalających. Powiedzmy, że twój pilot jest origin a twoja gałąź jest master. Jeśli ty git diff origin/master zanim zaczniesz ciągnąć, powinieneś mieć jakiś pomysł na potencjalne konflikty łączące i odpowiednio przygotować swój lokalny oddział.

Oprócz ciągnięcia i pchania, niektóre przepływy pracy angażować git rebase, taki jak ten, który parafrazuję z połączonego artykułu:

git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch

Jeśli znajdziesz się w takiej sytuacji, możesz ulec pokusie git pull --rebase. Jeśli naprawdę nie wiesz, co robisz, odradzam to. To ostrzeżenie pochodzi z man strona dla git-pull, wersja 2.3.5:

Jest to potencjalnie niebezpieczny tryb działania. Przepisuje   historię, która nie wróży dobrze, gdy opublikujesz tę historię   już. Nie używaj tej opcji, chyba że przeczytałeś git-rebase (1)   ostrożnie.


132
2018-05-15 20:53



@ JustinOhms If git pull --rebase nie jest właściwą rzeczą w danej sytuacji, czy jest to słuszne, jeśli odbywa się w dwóch etapach? Jeśli jest to słuszne, co jest dodatkową korzyścią, aby zrobić to w dwóch etapach? - Kaz
@Kaz - ponieważ rebase nie jest automatyczny. Pobieranie zmian w pierwszej kolejności umożliwia wykonanie połączenia oceniającego. To nie rozwiązuje problemu z ponowną historią, którą już popchnąłeś. Pozwoli to sprawdzić, czy można bezpiecznie dokonać zmian, których jeszcze nie pchnąłeś. - Justin Ohms
@JustinOhms W jaki sposób zdecydujesz, czy można bezpiecznie dokonać zmian? Po prostu spróbowałbym git rebase i cofnąłbym się, gdyby zrobił bałagan, w takim przypadku równie dobrze mógłbym zrobić git pull --rebase. Ale może masz jakiś inny sposób? - Kaz
@KaZ gitk pozwala wizualnie zobaczyć strukturę gałęzi. Pokaże on położenie twojej lokalnej głowy, pilotów i twoich struktur oddziału w stosunku do pobranych. W ten sposób możesz upewnić się, że nie zmieniasz przeniesionych zmian, które są oparte na przodku, który poprzedza to, co już przesłałeś do swoich pilotów. - Justin Ohms
Posługiwać się rebase kiedy pracujesz w lokalnym oddziale, który jeszcze nie został wypchnięty. Jeśli pracujesz na oddziale, które istnieje w pilocie, rebase może powodować pewne nieprzyjemne problemy, więc powinieneś preferować regularne merge. - Justus Romijn