为什么重新合并会导致git中的重复合并冲突？

Question

假设我们有一个“master”分支，在 2 年内提交了 1000 次。我们有一个长期存在的功能分支“feature1”，大约 2 个月大（当时从 master 分支），有 100 次提交。我们继续在 master 和 feature1 上工作，偶尔将 master 合并到 feature1 中（大约 5 次提交，每 2 天），以防止它漂移太远。每次我们这样做时，都会发生特定的合并冲突，每次都是相同的（我手动解决）。为了完整起见，在此示例中它是一个 JavaScript 项目。

我的问题：为什么 git 不“记得”我第一次如何解决这个冲突并在后续合并中使用相同的解决方案？

可能有助于回答的可选皱纹：

我的直觉是，如果我从 master 创建一个新分支，然后将 feature1 合并到结果中（我们称之为“master+feature1”），那么从 master 到 master+feature1 的后续合并将停止发生相同的合并冲突。在实践中，我相信我已经看到了这一点，尽管我没有证据。证明或解释会很有趣，我相信它可以帮助解释我的主要问题的答案。

我对这个问题的 rebase 不感兴趣。 （假设 feature1 被推送到共享远程并且不希望重新设置基准。）

Answer 1

如果您enable "rerere"，Git 可以并且会记住以前的解决方案。

如果没有更多细节，我无法说明为什么您将 master 合并到 feature1 会一直遇到同样的冲突。我只能描述合并工作的一般方法：它找到您正在合并的事物的“合并基础”（最近的共同祖先）（master）和您所在的分支（@987654325 @)，然后查找 (git diff) 自从这两个分支中的每个分支上的共同祖先以来所做的更改。如果只有一个“方面”改变了一些东西，那么那里应该没有冲突，所以“双方”必须做出改变——至少在运行git diff 方面——相互冲突。

如果您目前在分支 feature1¹ 并想查看自您最近的共同祖先以来 master 发生了什么变化：

git diff feature1...master   # three dots

要查看自那时以来feature1 本身发生了什么变化，请颠倒名称：

git diff master...feature1   # still 3 "."s

三点形式指示git diff 使用git merge-base 来查找合并基。然后根据右侧的名称进行差异。

---

¹实际上，您根本不必在分支上。如果您在在分支上，您可以使用HEAD 快捷方式：git diff ...master 和git diff master...。