什么时候是第二次运行“`git merge`停止报告任何冲突的必要条件和充分条件？

Question

当我跑的时候

git merge master

我正在将主分支合并到当前分支中。

当merge报告任何冲突时，我通过编辑报告的具有冲突的文件中的冲突，然后进行提交来解决冲突。

然后，我想确保我已经通过再次运行merge命令解决了所有冲突，看看它是否仍然报告任何冲突。我还没有看到merge命令的第二次运行仍然报告冲突的情况。但在我看来，当比较已更改的冲突区域与其原始内容时，我的功能分支上来自解决合并冲突的新提交很可能与主分支冲突。

那么，要使merge命令的第二次运行不报告任何冲突，对有冲突的文件进行哪些更改是必要的，也是足够的？

谢谢。

Answer 1

如果你说"git merge a- branch“和" a-branch”与你之前要求合并的分支完全相同，并且没有新的修订，那么它永远不会失败，因为无论该修订上的文件内容如何，在你第一次完成合并(并提交)之后，a- branch (提示处的修订)已经是当前分支的历史记录的一部分，因此git会认为“没有什么需要合并”(即使当前分支上的所有文件都已被修改)。

Answer 2

合并后没有冲突，即使看起来可能有冲突。

考虑合并之前和之后的分支。它可能看起来像这样：

师父：

 A -> B -> C

分支：

 A -> B -> D

因此分支出现了分歧，这就是您需要手动解决冲突的原因。在合并之后，您可能会看到如下所示：

分支：

A -> B -> C -> D -> E

其中E是新的合并后提交。现在，尽管在查看代码时看起来似乎存在冲突，但实际上git现在知道了更改应该以什么顺序发生。因此，它根本不会将所谓的冲突视为冲突，只是将其视为代码的正常演变。

我还想指出，根据我的经验，您通常不会将主分支合并到另一个分支，而总是从主分支分支，并在分支开发完成时合并回它。

遵循此协议可能会为您节省大量手动合并