Unterschied zwischen Git Pull und Git Pull - Basis

Ich habe vor einiger Zeit angefangen, Git zu verwenden und verstehe die Feinheiten nicht ganz. Meine grundlegende Frage hier ist, den Unterschied zwischen a git pullund herauszufinden git pull --rebase, da das Hinzufügen der --rebaseOption nichts ganz anderes zu tun scheint: nur ein Ziehen.

Bitte helfen Sie mir, den Unterschied zu verstehen.

git pull= git fetch+ git mergegegen Tracking Upstream Branch

git pull --rebase= git fetch+ git rebasegegen Tracking Upstream Branch

Wenn Sie wissen möchten, wie git mergeund sich git rebaseunterscheiden, lesen Sie dies .

Manchmal haben wir einen Upstream, der einen Zweig, von dem wir abhängig sind, neu basiert / zurückgespult hat. Dies kann ein großes Problem sein und zu chaotischen Konflikten führen, wenn wir nachgelagert sind.

Die Magie ist git pull --rebase

Ein normaler Git-Pull ist im Großen und Ganzen so etwas (in all diesen Beispielen verwenden wir eine Fernbedienung namens origin und einen Zweig namens foo):

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

Auf den ersten Blick könnte man denken, dass ein Git Pull - Rebase genau das tut:

git fetch origin
git rebase origin/foo

Dies hilft jedoch nicht, wenn die Upstream-Rebase ein "Squashing" beinhaltet (was bedeutet, dass sich die Patch-IDs der Commits geändert haben, nicht nur ihre Reihenfolge).

Was bedeutet, dass Git Pull - Rebase ein bisschen mehr als das tun muss. Hier ist eine Erklärung, was es tut und wie.

Angenommen, Ihr Ausgangspunkt ist folgender:

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

Die Zeit vergeht und Sie haben einige Verpflichtungen zusätzlich zu Ihrem eigenen "foo" eingegangen:

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

In einem Anfall von unsozialer Wut hat der vorgelagerte Betreuer nicht nur sein "Foo" neu begründet, sondern sogar ein oder zwei Kürbisse verwendet. Seine Commit-Kette sieht jetzt so aus:

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

Ein Git-Pull an diesem Punkt würde zu Chaos führen. Sogar ein Idiot holen; git rebase origin / foo würde es nicht schneiden, da Commits "b" und "c" auf der einen Seite und Commit "b + c" auf der anderen Seite zu Konflikten führen würden. (Und ähnlich mit d, e und d + e).

Was git pull --rebasein diesem Fall bedeutet, ist:

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

Dies gibt Ihnen:

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

Möglicherweise erhalten Sie immer noch Konflikte, aber es handelt sich um echte Konflikte (zwischen p / q / r und a / b + c / d + e / f) und nicht um Konflikte, die durch b / c-Konflikte mit b + c usw. verursacht werden.

Antwort von (und leicht modifiziert):
http://gitolite.com/git-pull--rebase

Angenommen, Sie haben zwei Commits in der lokalen Niederlassung:

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

Nach "git pull" wird sein:

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

Nach "git pull --rebase" gibt es keinen Zusammenführungspunkt G. Beachten Sie, dass D und E unterschiedliche Commits werden:

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

Im einfachsten Fall keine Kollisionen

• mit rebase: Rebasing Ihre lokale Commits ontop von Remote - Head und ist nicht erstellen merge / Merge - Commit
• ohne / normal: führt zusammen und erstellt ein Zusammenführungs-Commit

Siehe auch:

man git-pull

Genauer gesagt führt git pull git fetch mit den angegebenen Parametern aus und ruft git merge auf, um die abgerufenen Verzweigungsköpfe mit dem aktuellen Zweig zusammenzuführen. Mit --rebase wird git rebase anstelle von git merge ausgeführt.

Siehe auch:
Wann sollte ich git pull --rebase verwenden?
http://git-scm.com/book/en/Git-Branching-Rebasing

Dazu ist es wichtig, den Unterschied zwischen Merge und Rebase zu verstehen.

Bei Rebases sollten Änderungen von der Spitze der Hierarchie nach unten und bei Zusammenführungen nach oben zurückfließen.

Weitere Informationen finden Sie unter http://www.derekgourlay.com/archives/428