git pull --rebase 导致意外的图表

Question

我在一个分支上工作，foo。我没有未分级的更改，没有工作更改，完全干净的状态，根据我的盒子，HEAD == foo == origin/foo。

$ git status
# On branch foo
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   some_irrelevant_file_here

$ git log --pretty=...
* 456520c 2015-02-13 (HEAD, origin/foo, foo) Commit A
* 23bfcd1 2015-02-11 Commit B
* b0bdd18 2015-02-12 Commit C

然后我被要求查看同事推动的一些更改，所以我这样做了：

$ git pull --rebase origin foo
remote: Counting objects: 47, done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 36 (delta 22), reused 0 (delta 0)
Unpacking objects: 100% (36/36), done.
From ...
 * branch            foo       -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Fast-forwarded foo to 43dad88c737762e0f1e84fdcd135155080bdce2a.

此时，我的图表如下所示：

$ git log --pretty=...
* 43dad88 2015-02-13 (HEAD, foo) Commit D
* 40039f9 2015-02-13 Commit E
* 456520c 2015-02-13 (origin/foo) Commit A
* 23bfcd1 2015-02-11 Commit B
* b0bdd18 2015-02-12 Commit C

为什么我的本地foo 看起来比origin/foo 领先？ D 和 E 都不是我的提交，我只是从 origin 中提取了这两个 - 我希望此时仍然有 HEAD == foo == origin/foo。

Answer 1

pull --rebase 之前的情况是：

x--x--x (foo, HEAD, origin/foo)
       \
        y--y (actual origin/foo)

当您 pull --rebase 时，您要求在 origin/foo 之上重播本地提交：
foo 在 origin/foo 处重置/签出（在 FETCH_HEAD 中获取），并且由于您的提交 'x' 已经是新更新的FETCH_HEAD 的一部分，foo 只是快进：

x--x--x--y--y (foo, HEAD, FETCH_HEAD)
      |
 (origin/foo)

origin/foo没有改变的事实是 git older than 1.8.4 的典型特征（例如在 Ubuntu Precise 12.04 中找到，它与旧的 git-core 1.7.9.5 一起提供）

一个简单的git fetch 应该足以更新origin/foo，而不仅仅是FETCH_HEAD。

更新的 git (1.8.4+) 将同时更新 FETCH_HEAD 和 origin/foo，从而使额外的 git fetch 变得多余。

---

注意：使用 Git 2.12（2017 年第一季度），这种情况（pull --rebase）将是一个简单的快进合并。

见commit 33b842a（2016 年 6 月 29 日）Junio C Hamano (gitster)。 ^{（2016 年 12 月 19 日由 Junio C Hamano -- gitster -- 在 commit 2fb11ec 中合并）}

pull：快进“pull --rebase=true”

"git pull --rebase" 总是运行 "git rebase" 在获取 承诺作为新基地，即使新基地是 当前 HEAD 的后代，即我们还没有做任何工作。

在这种情况下，我们可以改为快进到新基地，而无需 调用变基进程。

Answer 2

因为它没有被推送到 repo，这是一种正常的行为。为什么你可以在 origin 之前进行本地提交？他们将永远处于领先地位。

Answer 3

为什么我的本地 foo 看起来在 origin/foo 之前？

foo 在remote/foo 之前是预期的，因为rebase plays back your current branch on top of the upstream branch。您将foo 重新定位在remote/foo 之上，因此foo 应该在remote/foo 之前。

HEAD == foo == origin/foo 根据我的盒子。

因此，提交的顺序也符合预期。以下是分支在变基或合并之前的外观，其中A 是远程的实际状态，C 是远程的陈旧表示。

D <------C (HEAD, foo, remote/foo) <------B <------A (remote/foo)

您正在执行相当于“快进”变基的操作。 IE。它对提交没有任何作用； remote/foo 上没有可播放的内容！结果应该只改变参考位置：

D <------C <------B <------A (HEAD, foo, remote/foo)

为什么我的本地 foo 看起来在 origin/foo 之前？

这是我无法回答的问题。在 rebase 之后，我再次期望 HEAD == foo == remote/foo 但事实并非如此。为什么在foo 变基到remote/foo 之后，后者似乎落后了？