git pull --rebase 在同事的 git push --force 后丢失提交

Question

我以为我了解 git pull --rebase 是如何工作的，但是这个例子让我很困惑。 我会猜到以下两种情况会产生相同的结果，但它们有所不同。

第一，有效的。

# Dan and Brian start out at the same spot:
dan$ git rev-parse HEAD
067ab5e29670208e654c7cb00abf3de40ddcc556

brian$ git rev-parse HEAD
067ab5e29670208e654c7cb00abf3de40ddcc556

# Separately, each makes a commit (different files, no conflict)
dan$ echo 'bagels' >> favorite_foods.txt
dan$ git commit -am "Add bagels to favorite_foods.txt"

brian$ echo 'root beer' >> favorite_beverages.txt
brian$ git commit -am "I love root beer"

# Brian pushes first, then Dan runs `git pull --rebase`
brian$ git push

dan$ git pull --rebase
dan$ git log
commit 9e1140410af8f2c06f0188f2da16335ff3a6d04c
Author: Daniel
Date:   Wed Mar 1 09:31:41 2017 -0600

    Add bagels to favorite_foods.txt

commit 2f25b9a25923bc608b7fba3b4e66de9e97738763
Author: Brian
Date:   Wed Mar 1 09:47:09 2017 -0600

    I love root beer

commit 067ab5e29670208e654c7cb00abf3de40ddcc556
Author: Brian
Date:   Wed Mar 1 09:27:09 2017 -0600

    Shared history

所以效果很好。 在另一种情况下，想象一下 Dan 推动，然后 Brian（粗鲁地）推动 --force 来完成他的提交。 现在，当 Dan 运行git pull --rebase ，他的提交就消失了。

# Dan and Brian start out at the same spot:
dan$ git rev-parse HEAD
067ab5e29670208e654c7cb00abf3de40ddcc556

brian$ git rev-parse HEAD
067ab5e29670208e654c7cb00abf3de40ddcc556

# Separately, each makes a commit (different files, no conflict)
dan$ echo 'bagels' >> favorite_foods.txt
dan$ git commit -am "Add bagels to favorite_foods.txt"

brian$ echo 'root beer' >> favorite_beverages.txt
brian$ git commit -am "I love root beer"

# THIS TIME, Dan pushes first, then Brian force pushes.
dan$ git push

brian$ git push --force

dan$ git pull --rebase
dan$ git log  # Notice, Dan's commit is gone!
commit 2f25b9a25923bc608b7fba3b4e66de9e97738763
Author: Brian
Date:   Wed Mar 1 09:47:09 2017 -0600

    I love root beer

commit 067ab5e29670208e654c7cb00abf3de40ddcc556
Author: Brian
Date:   Wed Mar 1 09:27:09 2017 -0600

    Shared history

在 Brian 的push --force之后，分支的原始版本与第一个场景中的状态相同，所以我期望git pull --rebase行为相同。 我很困惑为什么 Dan 的提交丢失了。

我理解 pull --rebase 说“进行我的本地更改，并在远程更改之后应用它们”。 我不希望本地更改会被丢弃。 此外，如果 Dan 运行了git pull （没有--rebase ），他的提交不会丢失。

那么为什么 Dan 在运行git pull --rebase时会丢失他的本地提交呢？ 强制推动对我来说很有意义，但难道不应该让遥控器保持与布赖恩首先推动的状态相同的状态吗？

我怎么想这个错误？

Answer 1

TL;DR：这是叉点代码

您正在获得git rebase --fork-point的效果，它也故意从您的存储库中删除 Dan 的提交。 另请参阅Git rebase - 在 fork-point 模式下提交选择（尽管在我的回答中我没有提到我会在这里的内容）。

如果您自己运行git rebase ，您可以选择是否使用--fork-point 。 --fork-point选项用于以下情况：

• 你在没有<upstream>参数的情况下运行git rebase （暗示了--fork-point ），或者
• 你运行git rebase --fork-point [<arguments>] <upstream> 。

这意味着要在没有应用--fork-point情况下--fork-point上游，您应该使用：

git rebase @{u}

或者：

git rebase --no-fork-point

一些细节取决于 Git 版本，因为--fork-point仅在 Git 2.0 版中成为一个选项（但自 1.6.4.1 以来一直由git pull秘密完成，方法变得越来越复杂，直到整个--fork-point东西被发明了）。

讨论

正如你已经知道的， git push --force粗鲁地覆盖了分支指针，删除了一些现有的提交。 但是，您期望您的git pull --rebase会恢复删除的提交，因为您自己已经拥有它。 为了命名方便，让我们使用你的命名，当 Brian 强制推送时，Dan 的提交被丢弃。 （作为助记符，让我们说“Dan got Dropped”。）

有时会！ 有时，只要您的 Git 在您的存储库中有 Dan 的提交，并且您的历史记录中有 Dan 的提交，当您重新设置提交时，Dan 的提交就会被恢复。 这包括您是丹的情况。 然而，有时它不会，这也包括你是丹的情况。 换句话说，它根本不是基于你是谁。

完整的答案有点复杂，值得注意的是，这种行为是您可以控制的。

关于git pull （不要使用它）

首先，让我们做一个简短的说明： git pull本质上只是git fetch然后是git merge或git rebase 。 ¹您可以通过提供--rebase或设置配置条目branch. branch-name .rebase来预先选择要运行的命令branch. branch-name .rebase branch. branch-name .rebase 。 但是，您可以自己运行git fetch ，然后自己运行git merge或git rebase ，如果您这样做，您就可以访问其他选项。 ²

其中最重要的是能够在选择主要选项（合并与变基）之前检查获取的结果。 换句话说，这让您有机会看到提交被删除。 如果您之前执行了git fetch并获得了 Dan 的提交，那么 - 无论是否有任何干预工作，您可能会或可能不会合并 Dan 的提交 - 完成第二次git fetch ，您将看到如下内容：

 + 5122532...6f1308f pu         -> origin/pu  (forced update)

请注意“（强制更新）”注释：这就是告诉您 Dan 被丢弃的原因。 （这里使用的分支名称是pu ，它是 Git 的 Git 存储库中的一个，它定期进行强制更新；我只是在这里剪切并粘贴了一个实际的git fetch输出。）

---

¹有几个细微的技术差异，尤其是在非常旧的 Git 版本中（1.8.4 之前）。 还有，正如我最近被提醒的，还有一个特殊情况，对于在当前分支上没有提交的存储库中的git pull （通常，进入一个新的空存储库）：这里git pull既不调用git merge也不调用git rebase ，而是运行git read-tree -m ，如果成功，则设置分支名称本身。

²我认为您可以在命令行上提供所有必要的参数，但这不是我的意思。 特别是，在 fetch 和第二步之间运行其他Git 命令的能力是我们想要的。

git rebase基础

要了解git rebase的主要和最基本的事情是它复制提交。 为什么本身是 Git 的基础：没有任何东西——没有人，也不是 Git 本身——可以改变提交（或任何其他 Git 对象）中的任何内容，因为 Git 对象的“真实名称”是其内容的加密哈希。 ³因此，如果你从数据库中取出一个提交，修改任何东西——即使是一点点——然后把对象放回去，你会得到一个新的、不同的哈希：一个新的、不同的提交。 它可能与原始提交极其相似，但如果其中有任何不同之处，则它是一个新的、不同的提交。

要查看这些副本如何工作，请至少绘制提交图的一部分。 该图只是一系列提交，从最新的或提示的提交开始，其真实名称哈希 ID 存储在分支名称中。 我们说名称指向提交：

            D   <-- master

提交，我已经叫D这里，包含（作为其散列的一部分提交数据），其母公司的哈希ID承诺，即承诺，这是该分支的末端，我们做之前D 。 所以它“指向”它的父级，它的父级指向更远的地方：

... <- C <- D   <-- master

内部箭头都像这样向后这一事实通常不是很重要，所以我在这里倾向于省略它们。 当一个字母的名字不是很重要时，我只是为每个提交画一个圆点：

...--o--o   <-- branch

为了从master branch “分支”，我们应该绘制两个分支：

A--B--C--D     <-- master
    \
     E--F--G   <-- branch

请注意，提交E指向回提交B 。

现在，如果我们想重新设置branch ，以便它在提交D （现在是master的提示）之后出现，我们需要将提交E复制到一个新的提交E' ，它“与C一样好”，除了它有D作为它的父级（当然还有一个不同的快照作为它的源库）：

           E'  <-- (temporary)
          /
A--B--C--D     <-- master
    \
     E--F--G   <-- branch

我们现在必须用F和G重复这一点，当我们都完成后，让名称branch指向最后一个副本G' ，放弃原来的链而支持新的：

           E'-F'-G'  <-- branch
          /
A--B--C--D           <-- master
    \
     E--F--G         [abandoned]

这就是git rebase的全部内容：我们挑选出一些要复制的提交； 我们将它们复制到某个新位置，一次一个，以父优先顺序（相对于更典型的子优先向后 Git 顺序）； 然后我们将分支标签重新指向上次复制的提交。

请注意，这甚至适用于空情况。 如果名称branch直接指向B并且我们在master对其进行变基，我们将复制B之后的所有零提交，将它们复制到D之后。 然后将标签branch重新指向上次复制的提交，即无，这意味着我们将branch重新指向提交D 。 在 Git 中，有几个分支名称都指向同一个提交是完全正常的。 Git 通过读取包含分支名称的.git/HEAD知道你在哪个分支。 分支本身——提交图的某个部分——由图决定。 这意味着“分支”这个词有歧义：请参阅“分支”究竟是什么意思？

另请注意，提交A根本没有父母。 这是存储库中的第一次提交：之前没有提交。 因此，提交A是根提交，这只是“没有父母的提交”的一种奇特方式。 我们也可以与两个或更多的父母一起提交； 这些是合并提交。 （不过，我没有在这里画任何东西。对包含合并的分支链进行 rebase 通常是不明智的，因为实际上不可能对合并进行 rebase，并且git rebase必须重新执行合并以近似它。通常git rebase只是完全省略合并，这会导致其他问题。）

---

³显然，根据鸽子洞原理，任何将较长的位串减少为固定长度的k位密钥的散列都必然会在某些输入上发生冲突。 Git 哈希函数的一个关键要求是避免意外冲突。 “加密”部分对 Git 来说并不是真正重要的，它只是让某人很难（但当然并非不可能）故意造成冲突。 冲突导致 Git 无法添加新对象，因此它们很糟糕，但是——除了实现中的错误——它们实际上并没有破坏 Git 本身，只是进一步使用 Git 来处理你自己的数据。

---

确定要复制的内容

变基的一个问题在于确定哪些提交要复制。

大多数时候，这似乎很简单：您希望 Git 复制您的提交，而不是其他人的。 但这并不总是正确的——在有管理员和经理等的大型分布式环境中，有时某人重新设定其他人的提交是合适的。 无论如何，这不是 Git 最初的做法。 相反，Git 使用图形。

命名一个提交——例如，写branch往往不仅会选择那个提交，还会选择那个提交的父提交、父提交，等等，一直回到根提交。 （如果有一个合并提交，我们通常会选择它的所有父提交，并同时跟随所有的提交回到根。一个图可以有多个根，所以这让我们可以选择多个链回到多个根，以及返回到单个根的分支和合并链。）当从一个提交开始并执行这些父遍历时，我们将找到的所有提交的集合称为可到达提交的集合。

出于许多目的，包括git rebase ，我们需要使这个整体选择停止，我们使用 Git 的奇特集合操作来做到这一点。 如果我们将master..branch写为修订选择器，这意味着：“所有提交都可以从branch的尖端到达，除了从master的尖端可以到达的任何提交。” 再看这张图：

A--B--C--D     <-- master
    \
     E--F--G   <-- branch

可从branch访问的提交是G 、 F 、 E 、 B和A 。 可从master到达的提交是D 、 C 、 B和A 。 所以master..branch意思是：从更大的 A+B+E+F+G 集合中减去 A+B+C+D 集合。

在集合减法中，删除一开始不存在的东西是微不足道的：你什么都不做。 所以我们从第二组中删除 A+B，留下 E+F+G。 或者，我喜欢使用我无法在 StackOverflow 上绘制的方法：将提交着色为红色（停止）和绿色（去），遵循图中的所有向后箭头，从红色开始表示被禁止的提交（ master ）和绿色用于提交（ branch ）。 只需确保红色覆盖绿色，或者先做红色，然后在做绿色时不要重新着色。 直觉上很明显⁴先做绿色，再用红色覆盖； 或者先做红色而不是覆盖，给出相同的结果。

无论如何，这是git rebase选择要复制的提交的一种方式。 变基文档将其称为<upstream> 。 你写：

git checkout branch; git rebase master

Git 知道将master提交着色为红色，当前branch提交为绿色，然后只复制绿色的。 此外，同样的名字- master -告诉git rebase放在哪里的份。 这是非常优雅和高效的：一个参数master告诉 Git要复制什么以及将副本放在哪里。

问题是，它并不总是有效。

有几种常见的情况下它会崩溃。 当您想进一步限制副本时会发生一种情况，例如，将一个大分支分成两个较小的分支。 另一种情况是，您自己的一些（但不是全部）提交已经被复制（樱桃挑选或壁球“合并”）到您要重新定位到的另一个分支中。 罕见但并非闻所未闻，有时上游故意丢弃一些提交，你也应该这样做。

对于其中一些情况， git rebase可以使用git patch-id处理它们：它实际上可以判断一个提交被复制了，只要两个提交具有相同的补丁 ID。 对于其他人，您必须使用--onto标志手动拆分 rebase目标（rebase 调用此<newbase> ）：

git rebase --onto <newbase> <upstream>

这将复制限制为<upstream>..HEAD的提交，同时在<target>之后开始复制。 这 - 将副本的目标与<upstream>参数分开 - 意味着您现在可以自由选择任何删除正确提交的<upstream> ，而不是由“副本去哪里”决定的某些集合。

---

⁴这是数学家在不想写出证明时使用的短语。 :-)

---

--fork-point选项

如果您定期将提交变基到origin/whatever分支（或类似分支），即其本身也定期以移除提交为目标进行变基，则可能很难决定要复制哪些提交。 但如果你有，你的origin/whatever引用日志，一系列的提交哈希值，显示一些提交前都在那里，但不再，有可能为混帐用这个来丢弃，从到副本集中，部分或全部那些提交。

我不完全确定--fork-point是如何在内部实现的（它没有很好的记录）。 对于这个答案，我做了一个测试存储库。 git merge-base --fork-point origin/master topic ，该选项依赖于顺序： git merge-base --fork-point origin/master topic返回与git merge-base --fork-point topic origin/master不同的结果。

对于这个答案，我查看了源代码。 这表明 Git 在第一个非选项参数的引用日志中查找 - 调用这个arg1 - 然后使用它来使用下一个这样的参数arg2来查找合并基础，该参数arg2解析为提交 ID，完全忽略任何其他参数。 基于此， git merge-base --fork-point $arg1 $arg2的结果本质上是⁵的输出：

git merge-base $arg2 $(git log -g --format=%H $arg1)

正如文档所说：

更一般地，在计算合并基础的两个提交中，一个由命令行上的第一个提交参数指定； 另一个提交是（可能是假设的）提交，它是命令行上所有剩余提交的合并。

因此，如果指定了两个以上的提交，则合并基础不一定包含在每个提交参数中。 当与--merge-base选项一起使用时，这与git-show-branch(1)不同。

因此，-- --fork-point尝试找到第二个参数的当前散列与上游当前值及其所有引用日志记录值的假设合并基之间的合并基。 这就是导致排除已删除提交的原因，例如此处示例中 Dan 的提交。

请记住，使用--fork-point模式仅在内部修改git rebase的<upstream>参数（同时不会更改其--onto目标）。 例如，假设有一次，上游有：

...--o--B1--B2--B3--C--D    <-- upstream
                 \
                  E--F--G   <-- branch

可以说，-- --fork-point是检测这种形式的重写：

...--o-------------C--D     <-- upstream
      \
       B1--B2--B3           <-- upstream@{1}
                \
                 E--F--G    <-- branch

并通过选择B3作为内部<upstream>参数来“敲除”提交B1 、 B2和B3 。 如果你离开了--fork-point选项，Git的一切意见这种方式来代替：

...--o-------------C--D     <-- upstream
      \
       B1--B2--B3--E--F--G  <-- branch

这样所有的B提交都是“我们的”。 上游分支上的提交是D 、 C和C的父o （及其父，到根）。

在我们的特殊情况下，Dan 的提交——被删除的提交——类似于这些B提交之一。 它与--fork-point一起--fork-point并保留在--no-fork-point 。

---

⁵如果使用--all ，这将产生多个合并基础，命令失败，并且不打印任何内容。 如果生成的（单一）合并基础不是已经在 reflog 中的提交，则该命令也会失败。 第一种情况发生在作为最近祖先的纵横合并。 第二种情况发生在所选祖先的年龄足以从 reflog 过期，或者一开始就没有在其中（我很确定这两种情况都是可能的）。 我这里有第二种失败的例子：

$ arg1=origin/next
$ arg2=stash-exp
$ git merge-base --all $arg2 $(git log -g --format=%H $arg1)
3313b78c145ba9212272b5318c111cde12bfef4a
$ git merge-base --fork-point $arg1 $arg2
$ echo $?
1

我认为跳过3313b78...的想法3313b78...这是我从文档中引用的那些“可能假设的提交”之一，但实际上这将是与git rebase一起使用的正确提交，而且它是在没有--fork-point情况下使用。

---

2.0之前的Git，以及结论

在 2.0 之前的 Git 版本（或者可能是 1.9 后期）中，正在git rebase git pull会计算这个分叉点，但git rebase从来没有。 这意味着如果你想要这种行为，你必须使用git pull来获得它。 现在git rebase有--fork-point ，您可以选择何时获取它：

• 如果你肯定希望它添加的选项。
• 如果您绝对不想要它，请使用--no-fork-point或显式上游（ @{u}如果您有默认上游就足够了）。

如果运行git pull ，则没有--no-fork-point选项。 ⁶ git pull origin master （假设当前分支的上游是origin/master ）是否像git rebase origin/master那样抑制分叉点，我不知道：我主要避免git pull 。 根据测试（请参阅下面的 Breaking Benjamin 评论），在 Git 2.0+ 中， git pull --rebase始终使用 fork-point 模式，即使有额外的参数。

---

⁶至少，到目前为止，我刚刚对其进行了测试以确保。

Answer 2

这是解决方案：

git reflog

在那里挖掘以找到丢失的提交 SHA。 然后...

git cherry-pick <SHA-of-the-commit-you-found>

Answer 3

这两种情况都不令人困惑，这就是push --force工作原理。

我不会解释第一个场景，因为你也明白这一点。 但是在第二种情况下，当brian$ git push --force发生这种情况时，brian 的本地存储库对 dan 向远程的推送一无所知。

所以它需要 brian 的本地副本并替换远程中的所有内容，因为它是一个force push 。

git pull和git pull --rebase之间的区别是，

git pull将比较 origin 和 local 的变化。 这就是为什么即使您有未提交的更改也可以git pull 。

git pull --rebase不会将更改与本地进行比较，但它会从原点获取所有内容。 这就是为什么你不能git pull --rebase如果有未提交的更改

希望你明白我说的话。 任何问题？？

Answer 4

是的，这看起来是对的。 Brian 的git push --force将把最新的提交设置为他在本地系统上的提交。 如果 Brian 首先拉取任何最新提交，然后git push --force结果将是相同的。

这是一个包含更多信息的好线程： Force "git push" to overwrite remote files

Answer 5

是的，您对git pull --rebase理解是正确的。

这是因为提交9e11404已推送到远程，而在那之后，提交2f25b9a是强制更新远程（如果从远程强制删除， 9e11404 ）。

当 Dan 执行git pull --rebase ，git 检测到9e11404并且 origin/branch 指向2f25b9a 。 但是 git think 9e11404已经存在于远程（ .git\\logs\\refs\\remotes\\origin\\branch update by push 9e1140410af8f2c06f0188f2da16335ff3a6d04c进行内容update by push 9e1140410af8f2c06f0188f2da16335ff3a6d04c ），所以它没有做任何rebase。 或者你可以使用git pull --rebase=interactive来验证，你会发现它显示noop to rebase。 如果您想手动将9e11404在 origin/branch 的顶部，您可以在交互窗口中添加pick 9e11404 ，结果将是您所期望的。