Git 二进制文件与 .gitattributes 中的 -diff

在 .gitattributes 中有以下等价内容：

*.chm binary

*.chm -diff

我努力了*.chm二进制文件，但恐怕它仍然可能尝试合并这些文件。是-diff更适合我打算做什么？

另外，在提交给定类型的文件后，此设置是否适用？

Thanks

谢谢你的提问，你问的是：

我努力了*.chm二进制文件，但恐怕它仍然可能尝试合并这些文件。是-diff更适合我打算做什么？

内置宏属性binary相当于：

[attr]binary -diff -merge -text

(ref: 定义宏属​​性 - Gitattributes https://git-scm.com/docs/gitattributes#_defining_macro_attributes)

所以从你的问题来看，害怕-diff over binary可能更合适：差别不大。通常两者都应该足够了，git 属性文档名称-diff将文件标记为二进制的最简单方法之一。那么为什么不选择它呢？.chm files?

请参阅以下示例，该示例显示了问题中某些属性的效果：

.gitattributes file
[1]                     | [2]                   | [3]
------------------------|-----------------------|------------------------
*.chm binary            | *.chm -diff           | *.chm binary
*.chm -diff             |                       |

$ git check-attr -a help.chm
------------------------|-----------------------|------------------------
help.chm: binary: set   | help.chm: diff: unset | help.chm: binary: set
help.chm: diff: unset   |                       | help.chm: diff: unset
help.chm: merge: unset  |                       | help.chm: merge: unset
help.chm: text: unset   |                       | help.chm: text: unset

REMARK: [1]上面的输出与单行相同*.chm -diff binary or *.chm binary -diff。强烈暗示所有这些在逻辑上都等同于*.chm binary and 不同的 to *.chm -diff.

对于这个问题如果-diff is more适合您的意图，这取决于其他git 属性在您的配置中以及您认为合适或不合适的。由于您没有在问题中分享它们，我可以认为它们的答案是未定义的（这里无意冒犯，属性可以设置、未设置或未定义）。但这样的话答案就不完整了。所以一切皆有可能，并且使用binarymarco-attribute 可以取消设置或定义先前已设置或未定义的属性merge and/or text属性在存储库配置中已经有效。

所以binary看起来比-diff对我来说只是为了按下答案（不太可能好），因为您担心合并二进制文件，这是binary取消设置的宏属性merge具有以下后果的属性：

Unset

将当前分支的版本作为暂定合并结果，并声明合并有冲突。这适用于没有明确定义的合并语义的二进制文件。

(ref: merge- 执行三向合并 - Gitattributes https://git-scm.com/docs/gitattributes#_merge)

这与使用相同binary内置合并驱动程序。所以就像binary宏属性建议，您将合并显式标记为“二进制”。

区别于-diff- 这也隐式地将文件标记为二进制文件 -binary宏属性does改变merge属性，因此取消设置diff属性允许有一个与未设置不同的merge属性合并驱动程序正在运行（这是现有答案正确的地方，使用binary不等于-diff- 它不完整地列出了宏观思想的属性，并错过了宏观思想的未设置merge属性 - 可能尚未记录正在使用的版本，可能是 git 版本

正如您可能想象的那样，这些都是非常精细的细节。简而言之-diff应该足够了，binary可能不会造成伤害，但会取消设置比正常需要更多的属性，因此在合并时更加明确（不提及text属性），但可能会产生不需要的副作用和/或使将来的维护变得更加困难（这是非常理论化的，但是它可能会做更多的事情，这让您一开始就感到害怕）。

我个人的答案是，不要害怕，遵循你自己的喜好-diff直到遇到实际问题。您很可能很久以前就已经解决了这个问题。

也感谢您提出的附加问题：

另外，在提交给定类型的文件后，此设置是否适用？

Yes.

如有疑问，请尝试使用$GIT_DIR/info/attributes（具有最高优先级），因为它是您的克隆本地的并且从未提交，然后使用进行验证git check-attr它如何影响已提交文件的属性。

Git 不会将每个提交的文件的属性存储在存储库中，仅存储在.gitattributes文件（如果已提交）。