Git二进制与.Git属性中的差异

In.gittributes具有以下等效属性：

*.chm binary

*.chm -diff

我已经尝试了

*.chm

二进制文件，但我担心它仍然会尝试合并这些文件。

-diff

是否更适合我打算做的事情

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

---

谢谢，它们不一样

binary

是一个内置的宏属性，表示

-diff-text

。有关详细信息，请参阅。

谢谢您的提问，您提出了以下问题：

我已经尝试了

*.chm

二进制文件，但我担心它仍然会尝试合并这些文件。

-diff

是否更适合我打算做的事情

内置宏属性二进制相当于：

[attr]binary -diff -merge -text

（参考号：）

因此，从您的问题来看，担心

-diff

超过

二进制

可能更合适：这没有多大区别。这两种方法通常都足够了，gitattributes文档名称

-diff

是将文件标记为二进制文件的最简单方法之一。那么为什么不为

.chm

文件使用它呢

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

.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

备注：

[1]

以上输出与单行

*.chm-diff binary

或

*.chm binary-diff

相同。这是一个强烈的提示，表明所有这些在逻辑上仅等同于

*.chm binary

，而不同于

*.chm-diff

对于

-diff

是否更适合您的意图的问题，它取决于配置中的其他属性，以及您认为合适与否。因为你没有在你的问题中分享它们，所以我可以认为它们没有答案。但是，答案并不完整。因此，任何事情都是可能的，使用二进制marco属性可能会取消设置或定义先前已设置或未定义的合并和/或文本属性，这些属性在存储库配置中已经有效

因此，

binary

看起来比

-diff

更可取，因为我只需要按一个答案（不太可能好），因为您关心的是合并二进制文件，而正是

binary

宏属性取消了

merge

属性的设置，其结果如下：

取消设置

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

（参考号：）

这与使用二进制内置合并驱动程序相同。因此，正如binary宏属性所建议的那样，可以将合并显式标记为“binary”

与

-diff

-不同的是，diff也会隐式地将文件标记为二进制文件-二进制宏属性会更改合并属性，因此取消设置diff属性允许使用与取消设置的合并属性不同的合并驱动程序（这就是现有答案正确的地方，使用

二进制

与

-diff

不同-它没有完整地列出宏思想的属性，并且错过了合并属性的取消设置-它可能没有为正在使用的思想版本记录，可能是git版本<1.7.12.4）

您可能可以想象，这些都是非常好的细节。简言之，

-diff

应该足够了，

二进制

可能不会造成伤害，但会取消设置比正常需要更多的属性，因此在合并时更加明确（不提及文本属性），但可能会产生不必要的副作用和/或使将来的维护更加困难（这是相当理论化的，但是它可能会做得更多，这让你一开始就感到害怕）

我个人的回答是，在遇到实际问题之前，不要害怕，遵循自己对

-diff

的偏好。很可能你早就解决了这个问题

---

还感谢您提出的其他问题：

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

对

如果有疑问，请使用

$GIT_DIR/info/attributes

（具有最高优先级）进行尝试，因为它是克隆的本地文件，并且从未提交，然后使用

GIT check attr

验证它如何影响已提交文件的属性

Git不会将每个提交的文件的属性存储在存储库中，只有在提交的情况下才将属性存储在

.gittributes

文件中