我可以配置 git 如何检测合并冲突吗

Question

我有一个可以比较和合并二进制文件的工具。 它还可以尝试自动合并所述二进制文件并在没有人为干预的情况下无法确定更改时中止。 是否可以配置 git 以使用我的工具来检测合并是否导致合并冲突？

例如，假设它可以处理 .png 文件。 如果我有两个分支 A 和 B，并且在分支 A 上对[150,100]处的像素进行了更改，而在分支 B 上对[200, 50]处的像素进行了更改。 如果我现在将分支 B 合并到分支 A 中，我的工具将检测到没有冲突的更改，并且只会自动合并图像而不会引发冲突。

Answer 1

据我所知，如果您尝试进行涉及两个 PNG 或其他二进制文件的合并，您将受到 Git 合并冲突检测算法的支配。 该算法通过文本文件中的更改来标记合并冲突，这些更改涉及彼此特定接近度内的差异（例如，彼此的几行内的更改）。

虽然您在 Git 中使用二进制合并工具并非不可能，但您可能需要对 Git 进行自定义构建/分叉才能实现。

但是，一般而言，您应该避免在 Git 中对二进制文件进行版本控制，因为它不能很好地处理二进制内容。

Answer 2

TL;DR：您需要一个合并驱动程序，您可以为.gitattributes某些文件声明.gitattributes 。 （驱动程序本身，您在.git/config 。请参阅gitattributes 文档。）

您无法配置 Git决定某些文件需要合并的方式。 决策算法太简单了，因为它包括：

1. 确定合并基础提交中的三个文件和两侧（左右，或我们的和他们的）。

   也就是说，假设合并库有一个名为path/to/abc.png并且两侧也有名为path/to/abc.png 。 Git 假定所有三个名称都代表相同的底层文件。

   例如，如果右侧（ --theirs ）侧没有path/to/abc.png ，但确实有different/path/to/xyz.png并且该文件似乎是新创建的（不存在于合并基）和xyz.png的内容与基的abc.png足够相似，Git 可能会选择用基的abc.png标识他们的xyz.png毕竟，但现在右侧有一个名称更改以及潜在的内容差异。 这是重命名文件的高级更改。

   同样，如果一方完全删除文件，这也是一个高层次的变化。 （如果双方都完全删除文件，这里没有问题：合并的结果只是“删除文件”。）因为没有不匹配的文件（例如这个新创建的xyz.png ）看起来足够相似。

2. 现在我们/Git 已将这三个文件标识为“相同”，如果以下任一情况为真，则需要进行非平凡合并：

   • 左右两边都改变了内容，变成了不同的内容。 也就是说，文件的左侧和右侧提交中的 blob 哈希不同，并且两者都不同于基本提交的 blob 哈希。 请注意，这并不意味着存在冲突！ 这只是意味着需要合并。

   • 或者，至少一个侧改变的内容，而另一侧由高电平变化，如重命名或删除该文件。 这自然是一个高级冲突。

如果此时检测到的冲突是高级别的冲突，Git会停下来寻求帮助。 但是，如果合适，它可能首先继续调用三个输入文件上的合并驱动程序。

撇开任何高级冲突或合并要求不谈，Git 现在决定是否对三个输入文件调用低级合并驱动程序。 如果（且仅当）发生这种情况：

• 实际上有三个文件（三个文件都没有丢失或删除），并且
• 所有三个的 blob 哈希值都不同。

低级合并驱动程序是您通过.gitattributes文件配置的驱动程序。 如果你没有通过.gitattributes配置一个，它要么是内置的文本文件合并驱动程序，要么是内置的二进制文件合并驱动程序。

内置的文本文件合并驱动程序尝试使用通常的 diff-and-stick-merge-conflict-markers-in 方法合并更改。 如果存在低级文本合并驱动程序无法解决的冲突，Git 将停止并寻求帮助。

内置的二进制文件合并驱动程序只是声明失败。 Git 会停下来寻求帮助。

如果您提供自己的合并驱动程序，则您有责任生成正确的合并结果和/或告诉 Git 停止并获得帮助。 因此，如果您有一个知道如何合并.png文件的合并驱动程序，您可以将其设置为*.png低级合并驱动程序。