我最近一直在阅读.gitattributes，也发现了像 https://github.com/alexkaratarakis/gitattributes 这样的地方，他们试图维护所有文件类型的gitattributes。 然而，在我的脑海中，浏览这些文件，我本能地认为这是一个无法维护的混乱。 这意味着您必须随时使用任何新的文件扩展名时更新该文件，或者任何软件都会弹出新的文件扩展名，这是不可能的。 当您与30 +人的团队合作时，维护这样的文件只是一场噩梦，我们几乎无法维护一个简单的图标.svg文件。
但与此同时，我已经在许多不同的项目中编码和使用 git 很多年了，我从来没有使用过 .gitattributes。 我们在项目中使用更漂亮的东西，它将换行符重写为"lf"，我们在 Windows 上有开发人员，这样的事情永远不会产生任何问题，vscode 也永远不会给这样的事情带来任何问题。 Git 还会自动拾取 pngs 等二进制文件，并自动显示 svg 等文件的文本差异，我从未进行过配置。
所以我问一个问题，真的有必要拥有这个文件吗？因为在我看来，它正在注册大量完全不必要的维护，而且 git 足够聪明，可以弄清楚它应该或不应该对文件做什么。
真的有必要有这个文件吗？
是的，对于与 Git 相关的任何设置(eol、diff、合并过滤器、内容过滤器等)，您希望存储库的任何协作者都遵循。
这与出于安全原因保持本地git config不同(因为它可能包含敏感信息或危险指令)
.gitattributes是版本化源代码的一部分，有助于建立通用的 Git 标准.
例如，我总是把(如VonC/gitcred/.gitattributes)：
*.bat text eol=crlf
*.go text eol=lf
因为无论您的 IDE/编辑器如何配置，我都需要CRLF 才能让我的 Windows bat 脚本正常运行，而我更喜欢 Go 文件的 LF，我在 Windows 或 Linux 上编辑这些文件。我一直认为像core.autocrlf这样的本地设置是一种反模式，最好留给false。
但是.gitattributes可以声明许多其他 Git 元素：
working-tree-encoding，用于翻译文件ident嵌入文件 SHA1，如下所示filter，最显着的是 Git LFS 使用，就像这里一样，我之前用过很多次。diff，至少要避免比较二进制文件，或定义外部差异驱动程序- hunk header(例如使用
xfunname)：我在这里提到它们。 - 像
unityyamlmerge一样合并过滤器 whitespace定义哪些diff和apply应考虑空格错误- 。
.gitattributes文件不是"强制性的"，而是 Git 工具箱中的一个有用工具，可以在项目代码库中安全地共享。
这取决于。.gitattributes文件最常见的用途是行结束处理、工作树编码和 Git LFS。 如果您使用的是 Git LFS，则需要将这些文件作为 LFS 文件进行处理。
否则，如果您只关心行尾，这取决于您的平台。 如果您的项目是仅限 Unix 的，则不需要它。 但是，如果您的项目可以跨系统使用，则通常有一个文件来指示哪些文件是文本(即，应进行行结束转换)以及哪些不是。 Git 经常猜对，但它只查看文件的开头，在许多情况下，某些文件类型(特别是 PDF)以一大块 ASCII 兼容文本开头，然后包含二进制数据，Git 需要帮助。
如果要包含 shell 脚本或批处理文件之类的内容，则绝对需要一个.gitattributes文件，因为 POSIX shell 不接受 CR 作为行尾的一部分，并且批处理文件必须包含 CRLF。 因此，可重复的行为需要eol=lf或eol=crlf。
同样，Windows上的一些人拥有尚未进入现代的工具(我们绝大多数使用UTF-8)，并且仍然绝对要求他们的数据采用带有BOM的小端UTF-16。 对于这些程序，通常工作树编码很重要，以便 Git 将它们内部存储为 UTF-8 文本，并且可以对它们执行差异和合并等操作。 如今，大多数编辑器和工具都可以很好地处理 UTF-8 和 LF，这可能就是您没有真正看到问题的原因。
如果您的项目将在 Windows 上使用，我强烈建议至少一个简单的* text=auto(如果没有别的)，因为这意味着人们不会意外地在您的文本文件中提交 CRLF 行尾，并且人们在跨系统工作时将拥有他们喜欢的行尾。 这是一个简单的步骤，可以使项目体验更好。