Question

我得知git pull --rebase origin master = git fetch origin master + git rebase origin/master。我正在使用 git 2.18

但是当我阅读this blog时，它并不总是这样。

（如果我理解有误，请从这里纠正我的意思）

该博客提供了一个示例来显示git pull --rebase的不同行为，否则我们都知道。

他说，

让我们假设你的出发点是这样的：

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

时间的推移，你有你自己的“富”的顶部做了一些提交：

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

同时，出于反社会的愤怒，上游维护者不仅重新设置了他的“ foo”，甚至还使用了一两个南瓜。他犯链现在看起来像这样：

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

在这一点上GIT中拉会导致   陷入混乱。即使是git fetch; git rebase origin/foo将不会削减它，   因为提交“b”和在一侧上的“C”，并提交“B + C”的   其他，会发生冲突。（并且与d，e和d + e类似）。

在这种情况下，git pull --rebase的作用是：

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

这给您：

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

您仍然可能会遇到冲突，但是   它们将是真正的冲突（P / Q / R和A / B + C / d + E / F之间），并且   不是由b / c与b + c冲突等引起的冲突。

我对本下列疑惑：

a）“ 此时进行git pull会导致混乱。”-为什么？由于默认情况下pull是非快进的，因此执行git fetch之后状态不会变成这样。哪里混乱？

a---b---c---d---e---p---q---r (foo)
 \
  b+c---d+e---f  (origin/foo)

b）若a）是真，git rebase origin/foo将容易地转换图形为：

a
 \
  b+c---d+e---f  (origin/foo)
               \ 
                b---c---d---e---p---q---r (foo)

我在哪里错了？为什么他说git fetch origin git rebase --onto origin/foo e foo将被执行？

Answer 1

关于（a），您是正确的，但结论（b）是错误的。

git rebase确实试图构造您在（b）中描述的历史记录。但是，请考虑一下更改b已经成为上游b+c的一部分时的样子。如果幸运的话，Git会注意到它们已经存在，并警告更改集现在为空。但是在更典型的情况下，b与b+c冲突。提交c，d和e的情况相同。

最后（一系列冗长的冲突解决方案），您会发现b，c，d和e中的所有内容都不应该被采用完全归结为基础，则可以继续进行生产性工作。最后，您将得出所需的历史记录：

a
 \
  b+c---d+e---f  (origin/foo)
               \ 
                p---q---r (foo)

git pull --rebase使您免于陷入困境，因为它知道您的p，q和r是您要重新确定基准的唯一提交。在幕后，它使用git merge-base --fork-point来发现e是上游提交，即不是您的分支的一部分。

了解git的拉--rebase

1 个答案: