我有一个可以比较和合并二进制文件的工具。如果存在未经人为干预无法确定的更改，它也可以尝试自动合并所述二进制文件并中止。 是否可以将git配置为使用我的工具来检测合并是否导致合并冲突？
例如，可以说它可以处理.png文件。
如果我有两个分支A和B，则分支A上[150,100]处的像素发生变化，分支B上[200, 50]处的像素发生变化。如果现在将分支B合并到分支A中，则我的工具将检测到没有冲突的更改，并且仅自动合并图像而不会引起冲突。
答案 0 :(得分：1)
据我所知，如果您尝试进行涉及两个PNG或其他二进制文件的合并，那么您将受到Git合并冲突检测算法的支配。该算法通过 text 文件中的更改来标记合并冲突，这些更改涉及彼此之间一定距离内的差异（例如，彼此之间几行之内的更改）。
虽然并非不可能在Git中使用二进制合并工具，但您可能必须对Git进行自定义构建/创建叉才能实现。
但是，通常，您应该避免在Git中对二进制文件进行版本控制，因为它不能很好地处理二进制内容。
答案 1 :(得分：1)
TL; DR：您需要一个合并驱动程序，该驱动程序是为.gitattributes中的某些文件声明的。 （驱动程序本身，您在.git/config中进行配置。请参见the gitattributes documentation。）
您无法配置Git如何决定某些文件需要合并。为此，决策算法太简单了，因为它包括：
标识合并基本提交中的三个文件以及两个侧面（左侧和右侧，或我们的侧面和侧面）。
也就是说，假设合并库中有一个名为path/to/abc.png的文件，并且双方也有一个名为path/to/abc.png的文件。 Git假定所有三个名称都表示 same 基础文件。
如果说右侧（--theirs）没有有path/to/abc.png，但是 有different/path/to/xyz.png < em>和该文件似乎是新创建的（在合并基础中不存在） xyz.png的内容与基础文件{{ 1}}，Git可能最终选择将其abc.png与基地的xyz.png进行标识，但现在右侧具有名称更改和潜在的内容差异。为文件重新命名是一个高级更改。
类似地，如果一侧完全删除文件，这也是一个高级更改。 （如果双方都完全删除了文件，则这里没有问题：合并结果只是“删除文件”。）因为没有 unmatched 文件，所以发生了一方或双方删除文件的决定。 （例如这个新建立的abc.png）看起来十分相似。
现在我们/ Git已将这三个文件标识为“相同”，如果以下两个条件均成立，则必须进行不重要的合并：
左右两侧都将内容更改为不同的内容。也就是说，文件的左侧提交和右侧提交中的Blob散列和与基本提交的Blob哈希不同。请注意，这并不意味着存在冲突！，仅表示需要合并。
或者，至少一侧更改了内容， 另一侧进行了高级更改，例如重命名或删除文件。这是自动的高级冲突。
如果此时检测到的冲突是高级别冲突，则Git 将停止并寻求帮助。但是，可以首先在适当的情况下继续在三个输入文件上调用合并驱动程序。
除了任何高级冲突或合并要求之外，Git现在决定是否在三个输入文件上调用低级合并驱动程序。这种情况仅在以下情况发生：
低级合并驱动程序是您通过xyz.png文件配置的驱动程序。如果您未通过.gitattributes进行配置，则它可能是内置文本文件合并驱动程序，也可能是内置二进制文件合并驱动程序。
内置文本文件合并驱动程序尝试使用通常的diff-and-stick-merge-conflict-markers-in方法合并更改。如果存在低级文本合并驱动程序无法解决的冲突，Git将停止并获得帮助。
内置的二进制文件合并驱动程序仅声明失败。 Git将停止并获得帮助。
如果您提供自己的合并驱动程序，则您负责产生正确的合并结果和/或告诉Git停止并获得帮助。因此，如果您有一个知道如何合并.gitattributes文件的合并驱动程序，则可以将其设置为.png的低级合并驱动程序。