假设我们有一个“主”分支，说有超过2年的1000次提交。我们有一个长寿命的功能分支“feature1”，大约2个月大（当时由master分支），有100个提交。我们继续在master和feature1上工作，偶尔将master合并到feature1（大约5次提交，每2天），以防止它漂移得太远。每次我们这样做，特定的合并冲突都会发生，每次都是相同的（并且我手动解决）。为了完整起见，在这个例子中它是一个JavaScript项目。
我的问题：为什么git不会“记住”我是如何第一次解决此冲突并使用相同的分辨率进行后续合并？
可选的皱纹可能有助于回答：
我的直觉是，如果我从master创建一个新的分支，然后将feature1合并到结果中（让我们称之为“master + feature1”），则随后从master到master + feature1的合并将停止发生相同的合并冲突。在实践中，我相信我已经看到了这一点，虽然我没有证据。证明或解释会很有趣，我相信它可以帮助解释我的主要问题的答案。
我对这个问题的变基不感兴趣。 （假设feature1被推送到共享远程，并且不希望使用变基。）
答案 0 :(得分：2)
如果你enable "rerere"，Git可以并且将会记住以前的决议。
如果没有更多详细信息，我无法说明为什么将master合并到feature1仍然会遇到同样的冲突。我只能描述合并工作的一般方法：它找到＆＃34;合并基础＆＃34; （你最近共同的祖先）你正在合并的东西（master）和你所在的分支（feature1），然后找到（git diff）自这个共同祖先以来在这两个分支中的每个分支上所做的更改。如果只有一个＆＃34; side＆＃34;已经改变了一些东西，那里应该没有冲突，所以＆＃34;双方＆＃34;必须进行更改 - 至少在运行git diff方面 - 相互冲突。
如果您目前正在分支feature1 1 上，并希望了解自您最近的共同祖先以来master中发生的变化：
git diff feature1...master # three dots
要了解自feature1本身以来发生了什么变化，请颠倒名称：
git diff master...feature1 # still 3 "."s
三点式表单指示git diff使用git merge-base查找合并基础。然后根据右侧的名称完成差异。
1 实际上，你根本不必在分支机构。如果 在分支机构上，您可以使用HEAD快捷方式：git diff ...master和git diff master...。