Git错误的无操作合并

Question

我在 Git 中看到一个奇怪的合并失败，在“压缩”合并到主控之后。

我创建了一个tiny GitHub repo 来重现该问题。

本质上，流程如下：

• 我创建了两个分支。
• 在一个分支中，我做了twocommits。
• 我将这些提交合并到第二个分支中。
• 我merge --squash'd these commits into master。
• 我deleted a file directly on the master branch。
• 然后我merged the changes in master back into the original branch。
  • 这就是问题发生的地方。此合并对分支产生无更改。在 master 上删除的文件仍然存在。
• 我将这个最新分支上的所有内容都拉到了第二个分支中。
• 我开了一个pull request来证明把第二个分支合并到master会重新引入之前删除的文件。

这里发生了什么？为什么从 master 合并回分支不包括直接对 master 分支所做的更改？这是错误还是使用错误？

Answer 1

这不是错误。问题是你的squash commit不是合并，所以git不知道它连接到Branch-1。它认为这是一个普通的提交。当您将master 合并到Branch-1 中时，git 会看到由于这些分支出现了以下变化：

• 在master：添加file1和file2，然后删除file1。总体差异：添加了file2。
• 在Branch-1：添加file1，添加file2。总体差异：添加了file1 和file2。

Git 使用这些整体差异合并分支。您在两个分支中添加了file2，但没有合并冲突，因为两个分支中的file2s 是相同的。所以合并的结果是一个提交，包含file1 和file2。

出于同样的原因，您的拉取请求会将file1 添加到master。

但是如果你做了一个真正的合并而不是一个 squash，结果会如你所愿。

---

其实git help merge里也提到了这个：

对于使用 3 路合并的策略（包括默认策略，递归），如果在两个分支上都进行了更改，但后来又在其中一个分支上恢复，则该更改将存在在合并结果中；有些人觉得这种行为令人困惑。这是因为在执行合并时只考虑头部和合并基础，而不是单个提交。因此，合并算法将恢复的更改视为根本没有更改，并替换为更改的版本。