git - 为什么重新 merge 会导致git重复 merge 冲突？

Question

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

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

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

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

我对这个问题的 rebase 不感兴趣。 (假设 feature1 被推送到一个共享的远程并且 rebase 是不可取的。)

Answer 1

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

如果没有更多细节，我无法说明为什么将 master merge 到 feature1 中会一直遇到同样的冲突。我只能描述 merge 工作的一般方法:它找到你正在 merge 的东西的“merge 基础”(最近的共同祖先)(master)和你的分支重新打开 (feature1)，然后找到 (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 查找 merge 基。然后根据右侧的名称进行差异比较。

---

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