Różnica między git pull a git pull --rebase

Kiedyś zacząłem używać git i nie do końca rozumiem zawiłości. Moje podstawowe pytanie tutaj polega na ustaleniu różnicy między git pulla git pull --rebase, ponieważ dodanie --rebaseopcji nie wydaje się robić czegoś zupełnie innego: wystarczy pociągnąć.

Pomóż mi zrozumieć różnicę.

git pull= git fetch+ git mergeprzed śledzeniem gałęzi upstream

git pull --rebase= git fetch+ git rebaseprzed śledzeniem gałęzi upstream

Jeśli chcesz wiedzieć jak git mergei czym się git rebaseróżnią, przeczytaj to .

Czasami mamy upstream, który zmienił / przewinął gałąź, od której jesteśmy zależni. To może być duży problem - powodując dla nas bałaganiarskie konflikty, jeśli jesteśmy na niższych szczeblach.

Magia jest git pull --rebase

Normalne ściąganie git jest, mówiąc luźniej, czymś takim: (we wszystkich tych przykładach użyjemy zdalnego o nazwie origin i gałęzi o nazwie foo):

# assume current checked out branch is "foo"
git fetch origin
git merge origin/foo

Na pierwszy rzut oka możesz pomyśleć, że git pull --rebase robi to:

git fetch origin
git rebase origin/foo

Ale to nie pomoże, jeśli rebase poprzedzający wiązałby się z jakimś „squashingiem” (co oznacza, że ​​zmieniono łatki commits, nie tylko ich kolejność).

Co oznacza, że ​​git pull --rebase musi zrobić coś więcej. Oto wyjaśnienie tego, co robi i jak.

Powiedzmy, że Twoim punktem wyjścia jest:

a---b---c---d---e  (origin/foo) (also your local "foo")

Czas płynie, a na twoim własnym „foo” dokonałeś pewnych zmian:

a---b---c---d---e---p---q---r (foo)

Tymczasem, w przypływie antyspołecznej wściekłości, opiekun wyższego szczebla nie tylko zmienił swoje „foo”, ale nawet użył squasha lub dwóch. Jego łańcuch zatwierdzeń wygląda teraz następująco:

a---b+c---d+e---f  (origin/foo)

Git pull w tym momencie spowodowałby chaos. Nawet git fetch; git rebase origin / foo nie wyciąłby go, ponieważ zatwierdza „b” i „c” z jednej strony, a zatwierdza „b + c” z drugiej, powodowałoby konflikt. (I podobnie z d, e i d + e).

Co git pull --rebaserobi, w tym przypadku, to:

git fetch origin
git rebase --onto origin/foo e foo

To daje ci:

 a---b+c---d+e---f---p'---q'---r' (foo)

Nadal możesz mieć konflikty, ale będą to prawdziwe konflikty (między p / q / r a a / b + c / d + e / f), a nie konflikty spowodowane przez b / c sprzeczne z b + c itp.

Odpowiedź pochodzi z (i nieznacznie zmodyfikowano):
http://gitolite.com/git-pull--rebase

Załóżmy, że masz dwa zatwierdzenia w oddziale lokalnym:

      D---E master
     /
A---B---C---F origin/master

Po „git pull” pojawi się:

      D--------E  
     /          \
A---B---C---F----G   master, origin/master

Po „git pull --rebase” nie będzie punktu scalania G. Zauważ, że D i E stają się różnymi zatwierdzeniami:

A---B---C---F---D'---E'   master, origin/master

W najprostszym przypadku braku kolizji

• z rebase: bazuje na lokalnych zatwierdzeniach na zdalnym HEAD i nie tworzy scalenia / zatwierdzenia scalania
• none / normal: scala i tworzy zatwierdzenie scalania

Zobacz też:

man git-pull

Dokładniej, git pull uruchamia git fetch z podanymi parametrami i wywołuje git merge, aby scalić odzyskane głowy gałęzi z bieżącą gałęzią. W przypadku --rebase uruchamia git rebase zamiast git merge.

Zobacz także:
Kiedy powinienem używać git pull --rebase?
http://git-scm.com/book/en/Git-Branching-Rebasing

Jest to ważne, aby zrozumieć różnicę między Scalaniem a Rebase.

Rebase to sposób, w jaki zmiany powinny przechodzić od szczytu hierarchii w dół, a scalanie to, jak przepływają z powrotem w górę.

Aby uzyskać szczegółowe informacje, patrz - http://www.derekgourlay.com/archives/428