假设我们有一个“主”分支机构，在两年内有1000个承诺。我们有一个长寿的功能分支“feature1”，大约2个月大（当时从master分支），有100个提交。我们继续在master和feature1上工作，并且偶尔将master合并到feature1（大约每2天提交5次），以防止它漂得太远。每次我们这样做时，都会发生一个特定的合并冲突，每次都是相同的（我手动解决）。为了完整起见，在本例中，它是一个javascript项目。
我的问题：为什么git不“记住”我第一次是如何解决这个冲突的，并在随后的合并中使用相同的解决方案？
可选皱纹，可能有助于回答：
我的直觉是，如果我从master创建一个新分支，然后将feature1合并到结果中（我们称之为“master+feature1”），相同的合并冲突将停止发生，随后从master合并到master+feature1。实际上，我相信我已经看到了，虽然我没有证据。证明或解释会很有意思，我相信这会有助于解释我主要问题的答案。
我对这个问题不感兴趣。（假设Feature1被推送到共享远程，并且不需要重新调整位置。）
最佳答案
如果您enable "rerere"，git可以并将记住以前的分辨率。
如果没有更多的细节，我无法解释为什么您将master合并到feature1时会遇到同样的冲突。我只能描述合并工作的一般方法：它找到要合并的对象（master）的“合并基”（最新的共同祖先）和您所在的分支（feature1），然后在这两个分支中的每个分支上查找自该共同祖先以来所做的（git diff）更改。如果只有一个“边”改变了某些东西，那么这里应该没有冲突，所以“双方”必须做出至少在运行时相互冲突的改变。
如果您当前在branchgit diff1上，并且希望查看自您最近的共同祖先以来feature1中发生了什么变化：
git diff feature1...master # three dots
要查看此后
master本身的变化，请反转名称：git diff master...feature1 # still 3 "."s
三点格式指示
feature1使用git diff查找合并基。然后对右侧的名称执行diff。实际上，你根本不必在分公司工作。如果您在分支上，您可以使用
git merge-base快捷方式：HEAD和git diff ...master。