为什么 Github 上的“压缩合并”总是可以实现快进？

Question

Github文档说

使用快进选项合并具有压缩提交的拉取请求。

这与我对正在发生的事情的心理模型（如下图所示）相冲突，如果能得到一些澄清，我将不胜感激。

初始情况，功能应该被“压缩并合并”到主版本中：

挤压后合并前的情况：

现在将功能合并到主版本中时如何执行快进合并？

编辑：所以从评论来看，似乎发生的实际上是“挤压和变基”而不是“挤压和合并”。它是否正确？

Answer 1

该文档所说的内容在技术上是正确的，但有些误导。

当您执行压缩并与 GitHub 合并时，它会获取两个分支的内容并将它们合并，但不会创建合并提交。相反，它创建一个只有一个父级的提交。这相当于git merge --squash && git commit在命令行中。

master在你的图中，这是和的合并feature。

GitHub 创建的临时提交随后会作为快进合并合并到您的主分支中，因为它必然是主分支的超集。这就是为什么它在技术上是正确的，但却具有误导性。GitHub 包含此消息是为了告诉您它不会创建合并提交（即具有两个或多个父级的提交），而是创建仅将主分支作为其父级的单个提交。

因此本质上，挤压和合并只是合并，但具有不同的历史。有一个提交具有单个父级，而不是多个提交与合并提交相结合。例如，如果你有这个：

A - B - C - D (dev)
 \
  E - F - G (feature)

如果你想合并D和G，正常的合并会给你这个：

A - B - C - D - H (dev)
 \             /
  E - F - G --    (feature)

南瓜合并会给你这个：

A - B - C - D - H' (dev)

H和的内容H'相同，但提交的父项数量不同。这H将通过创建但不提交H临时分支然后快进将其合并到dev.

如果首先发生挤压，则此行为可能与挤压和变基不同，因为一种情况可能会发生冲突，而另一种情况可能不会发生冲突。但在没有冲突的情况下，它们几乎总是会产生相同的结果。

压缩并合并和压缩并变基是否不同取决于所使用的变基类型。旧式am变基使用补丁，因此如果上下文在多个位置相同，则补丁可能会被误用，这是该方法的一个已知缺陷。它也不执行重命名检测，这意味着合并尝试可能会失败。较新风格的 rebase 在幕后使用了合并机制，我不知道在任何地方它不会产生相同的结果（尽管我不是 Git 合并机制专家），因为它本质上是一个合并。

请注意，基于合并的 rebase 的挤压和变基与基于合并的变基或挤压和合并在本质上与变基和挤压不同，因为后者涉及对多个补丁进行变基，每个补丁都可能存在冲突，而挤压和合并rebase 将仅考虑旧基础、新基础和压缩的提交。如果中间的补丁会导致冲突，但最终结果不会（例如，因为冲突的代码在本系列的后面被删除），那么 rebase-and-squash 将遍历有问题的提交和冲突，而 squash- and-rebase 不会成功，也将会成功。