.gitattributes 文件对于 git 真的有必要吗？

Question

我最近阅读了一些关于 .gitattributes 的文章，还发现了像这样的地方，https://github.com/alexkaratarakis/gitattributes，他们试图在其中维护所有文件类型的 gitattributes。但在我心里，翻看那些文件，我本能地认为这是一个难以维护的烂摊子。这意味着每当您使用任何新的文件扩展名或任何软件产生新的文件扩展名时，您都必须更新该文件，这是不可能的。当你与一个超过 30 人的团队一起工作时，维护这样的文件简直就是一场噩梦，我们几乎无法维护一个简单的 icon.svg 文件。

但除此之外，我多年来一直在许多不同的项目中编码和使用 git，但我从未使用过 .gitattributes。我们在项目中使用 prettier 之类的东西，将换行符重写为“lf”，并且我们在 Windows 上有开发人员，这样的东西永远不会出现任何问题，vscode 也永远不会出现任何此类问题。Git 还会自动选取 png 等二进制文件，并自动显示 svg 等文件的文本差异，我从来不需要配置它。

所以我想问一下，这个文件真的有必要吗？因为在我看来，它正在签署大量完全没有必要的维护，而且 git 足够聪明，可以弄清楚它应该或不应该对文件做什么。

Answer 1

真的有必要拥有这个文件吗？

是的，对于与 Git 相关的任何设置（eol、diff、合并过滤器、内容过滤器……），您希望存储库的任何协作者都遵循。

这与git config出于安全原因而保留在本地的情况不同（因为它可能包含敏感信息或危险指令）

A.gitattributes是版本化源代码的一部分，有助于建立通用的 Git 标准。
例如，我总是输入（如VonC/gitcred/.gitattributes）：

*.bat   text eol=crlf
*.go    text eol=lf

因为无论你的 IDE/编辑器如何配置，我的 Windows bat 脚本都需要CRLF 才能正确运行，而且我更喜欢在 Windows 或 Linux 上编辑的 Go 文件中使用LF 。我总是将本地设置视为core.autocrlf反模式，最好留给false.

但是 a.gitattributes可以声明许多其他 Git 元素：

• working-tree-encoding，用于翻译文件
• ident嵌入文件 SHA1，如下所示
• filter，最著名的是Git LFS使用的，就像这里一样，我之前使用过很多 次 。
• diff，至少避免比较二进制文件，或定义外部比较驱动程序
• hunk header （xfunname例如使用）：我在这里提到它们。
• 合并过滤器就像unityyamlmerge
• whitespace定义什么diff以及apply应该考虑空格错误
• ...

该.gitattributes文件不是“强制”的，而是 Git 工具箱中的一个有用工具，可以在项目代码库中安全地共享。

即使在裸存储库中您也可以阅读它：

在 Git 2.43（2023 年第 4 季度）中，属性子系统学会了遵守指定从attr.tree哪个树读取文件的配置.gitattributes。

请参阅John Cai ( )提交的提交 9f9c40c和提交 2386535（2023 年 10 月 13 日）。^{（由Junio C Hamano 合并 -- --于2023 年 10 月 30 日提交 26dd307）}john-cai
gitster

attr: 裸仓库时从 HEAD 读取属性

^{签字人：蔡约翰}

44451a2的动机（attr：teach，2023-05-06，Git v2.41.0-rc1 -- merge）（attr：teach "--attr-source="git" 的全局选项，2023-05-06），是为了使其可以gitattributes与裸存储库一起使用。

然而，为了更容易gitattributes在裸存储库中读取，我们只设置HEAD:.gitattributes默认值。
这与 mailmap 的工作方式一致，8c473ce（“ mailmap：裸存储库中的默认 mailmap.blob”，2012-12-13，Git v1.8.2-rc0 - merge）。

并且，仍然使用 Git 2.43（2023 年第 4 季度）：

请参阅John Cai ( )提交的提交 9f9c40c和提交 2386535（2023 年 10 月 13 日）。^{（由Junio C Hamano 合并 -- --于2023 年 10 月 30 日提交 26dd307）}john-cai
gitster

attr：添加attr.tree用于设置要从中读取属性的树状结构

^{签字人：蔡约翰}

44451a2（attr：teach，2023-05-06，Git v2.41.0-rc1 -- merge）（attr：teach“--attr-source =”全局选项“ git”，2023-05-06）提供了通过的能力以树形作为 attr 源。
然而，在像我们在 GitLab 那样将 Git 存储库作为裸存储库提供服务的情况下，通过设置一次来指向所有命令的 HEAD 会更容易--attr-source。

attr.tree添加允许此操作的新配置。

git config现在包含在其手册页中：

attr.tree

对存储库中从中读取属性的树的引用，而不是对.gitattributes工作树中的文件的引用。

在裸存储库中，默认为HEAD:.gitattributes.

如果该值未解析为有效的树对象，则使用空树。
当使用GIT_ATTR_SOURCE环境变量或--attr-source 命令行选项时，该配置变量不起作用。