【问题标题】：Git line endings after normalization: Good or bad practices?规范化后的 Git 行尾：好的做法还是坏的做法？
【发布时间】：2018-12-17 11:18:07
【问题描述】：

我已经阅读了很多关于 git 的行尾规范化的内容，并且已经了解到 .gitattributes 似乎是要走的路。但是我阅读了很多关于行尾标准化的利弊，尤其是在 windows 上。所以对我来说问题是......

行尾标准化是好还是坏？

我还研究了更大的存储库，但我从未见过任何类型的行尾规范化 f.e. Qt。

所以对我（或其他人）来说，你，这篇文章的读者，使用什么真的很有趣？你对这个话题有什么看法。

【问题讨论】：

您的问题可能会以“主要基于意见”的方式结束，坦率地说，它可能就是这样。所以快速评论（不是答案）我自己的意见：是的，绝对使用.gitattributes（不要不依赖core.autocrlf，因为它要求每个人都有相同的设置，这将不可避免地因人性而异）。即使您完全是 Windows 商店，也可能仍然是进行转换的最佳做法。回到过去，一些 Git 命令在带有 CRLF 行结尾的文件上失败了......
这大部分（完全？）都是固定的，但除非你有一个令人信服的理由来避免标准化（巨大的存储库和过滤器的速度正在伤害你等），那么它可能仍然是一个最佳实践进行转换。如果您确实将非 Windows 开发人员添加到团队中，您会更开心。

标签： git normalization line-endings

【解决方案1】：

如果您的 Git 项目会因任何原因在多个平台上被人们使用，您将需要使用 Git 的行尾规范化。非 Windows 系统上的用户不希望使用 CRLF 结尾，因为在这些平台上，回车往往会在 Git diff 输出中显示为尾随空格。但是，Windows 工具（包括编辑器和编译器）通常需要 CRLF 结尾才能工作。如果不使用行尾归一化，用户很可能会犯错误并不小心提交了错误的行尾，从而导致 diff 噪声。

话虽如此，您不必使用.gitattributes 来处理行尾。在 Windows 上使用 core.autocrlf 设置通常就足够了，因为 Git 可以检测大多数二进制文件而不更改它们的结尾，同时更改任何文本文件的行结尾。如果这适合您的存储库，则根本不需要 .gitattributes 文件。

【讨论】：

core.autocrlf 的问题不在于检测二进制文件（.gitattributes 进行相同的检测），而在于设置的位置。如果您尝试使用core.autocrlf，那么您需要在每个人的安装中协调配置。有人将不可避免地将core.autocrlf 设置为错误的东西，有些人会检查\r\n，其他人只是\n，工作目录会显得很脏。 .gitattributes 在签入后强制为每个人设置相同的设置。.gitattributes总是首选。
老实说，如果您在 Windows 上工作，core.autocrlf 是 Git 按预期工作的基本要求。没有充分的理由（除了历史存储库）不设置它。可能是.gitattributes比较万无一失，但是在标准化的开发环境或者小部分开发者中，core.autocrlf确实够用了。
没有“更万无一失”，有“万无一失”而不是。 core.autocrlf 不是。它已经过时，不应依赖。告诉人们它“足够好”会保留损坏的存储库，并带有错乱的行尾组合。