Różnica między git pull --rebase, git rebase i git merge

Question

Czy ktokolwiek może to wyjaśnić, pamiętając o zdalnych repozytoriach?

Answer 1

to droga, aby zaktualizować swoją gałąź rozwojową - te gałęzie zazwyczaj nie są publikowane dla innych (poza możliwością obejrzenia), więc przepisywanie historii nie jest problemem i naprawdę nie chcę scalać etc w takim oddziale.

git merge dokonuje scalenia; zobacz stronę podręcznika dla szczegółów - komand ma mnóstwo opcji, których nie można tu wyjaśnić.

git rebase wykonuje rebase, czyli przepisuje historię ponownie. Przejmie twoje zatwierdzenia do momentu, w którym będą się różnić od innego oddziału, usuń je tymczasowo, zastosuj brakujące zatwierdzenia z innego oddziału, a następnie ponownie zastosuj zatwierdzenia. git rebase posiada również tryb interaktywny, w którym można usuwać/modyfikować/łączyć (squash) określone zatwierdzenia.

Zajrzyj na stronę http://learn.github.com/p/rebasing.html, gdzie znajdziesz kilka ciekawych wykresów dotyczących działania rebase.

Answer 2

git rebase pozwala odłączyć gałąź od punktu, w którym się rozdzieliła, i ponownie podłączyć ją na drugą gałąź. git merge zamiast tego po prostu łączy zmiany z innej gałęzi w bieżącej gałęzi, bez ponownego wczytywania historii.

Jeśli nie ma żadnych konfliktów, wynik jest identyczny między seryjnej i rebase, ale historia jest inna:

(merge branch on master): 
master --A--B--C--E 
       /
branch   --D 

(rebase branch onto master): 
master  --A--B--C--D' 

W pierwszym przypadku seryjnej tworzy branch oddział połączyły się master, co prowadzi do powstania zatwierdzenie scalenia, E. W drugim przypadku D jest po prostu ponownie podłączany do master, tworząc kolejny commit, D'.

git pull --rebase spowoduje pobranie zmian z pilota i ponowne umieszczenie zmian na górze. Dosłownie zarejestruje wprowadzone zmiany, które nie są na pilocie, i odtwarza je, poczynając od ostatniej zmiany, która została właśnie pobrana.