Question

最近我启用了diff3，现在解决冲突要容易得多。

以前在某些情况下，我必须检查日志，看看为什么人们会这样做以及进行合并。但是使用diff3，信息会全部显示在一个地方

<<<<<<< HEAD
THIS IS USEFUL
||||||| merged common ancestors
This is useful
=======
This is really useful
>>>>>>> c2392943.....

由此我们可以很容易地看到结果应该是“这真的很有用”

我想知道diff3是否有任何缺点？为什么它不是git的默认行为？

Answer 1

对于其他读者（和from this article）：

git有一个以diff3格式显示合并冲突的选项（默认情况下，它只显示要合并的两个文件）。您可以这样启用它：

git config --global merge.conflictstyle diff3

你真的没有理由不启用diff3风格，因为你经常需要祖先来确定正确的合并是什么。

这是fairly early (2008)引入的，我认为它不是默认值，因为默认的unix diff不会显示为3向差异。

如上所述in this thread，如果你想在没有设置配置的情况下运行这个命令，那么你可以轻松地在普通差异和diff3之间切换，这在一个特定的情况下是可能的：

如果索引中标记了冲突（即，在冲突的合并之后，但在将路径标记为已解决之前，您所处的状态），则可以执行以下操作：

git checkout --conflict=diff3 <path...>

请注意，这实际上是将索引内容签出到工作树中，因此您对冲突的工作树副本所做的任何编辑都将被覆盖。

Answer 2

diff3应该是默认值。它不仅对于解决冲突很有用，而且使解决冲突可能。实际上，仅使用默认合并是不可能正确解决冲突的冲突风格。我建议所有人在其全局选项中设置diff3。

git config --global merge.conflictStyle diff3

为什么这实际上是不可能的？考虑一个添加了一个功能foo1在特定的源文件位置

def foo1():
    print("foo1")

和另一个在同一位置添加功能foo2的分支

def foo2():
    print("foo2")

如果我将另一个作为基础，则会发生冲突。默认合并将会显示冲突样式

++<<<<<<< HEAD
 +def foo1():
 +    print("foo1")
++=======
+ def foo2():
+     print("foo2")
++>>>>>>> Add foo2

冲突标志告诉我什么？他们告诉我需要同时{em>添加 foo1和foo2到文件中，对吗？不幸的是没有！考虑其中foo1和foo2已经存在的文件存在，还有两个分支，其中一个删除foo1，其中一个删除删除foo2。如果我将另一个作为基础，结果如何？的默认的合并冲突样式将显示

++<<<<<<< HEAD
 +def foo1():
 +    print("foo1")
++=======
+ def foo2():
+     print("foo2")
++>>>>>>> Remove foo1

在默认冲突样式下，删除两个函数的情况是与添加两个功能的情况完全没有区别（除了提交消息的文本，该文本只能是暗示）！因此，不足以达到目的解决冲突。这可能解释了为什么解决冲突被视为一门黑暗的艺术。 diff3不仅使它成为可能，而且常常使它变得容易。

Answer 3

为什么它不是git的默认行为？

我认为这不是默认设置，因为git mergetool始终在顶部显示3个面板：本地，基本（共同祖先）和远程+底部的第4个面板，其内容与您在问题中所写的相同。

因此，如果打开diff3并使用mergetool，则会在中间的顶部面板和||||||||之间的区域中复制信息。和========在底部面板中。