对于包含不一致的行尾以及使用 ascii 和 UTF-8(带 BOM)的文件编码的大型现有存储库...
关键是当前的文件集相当不一致。它们的编码不同。 (让我们暂时忽略 UTF-16，尽管我也有一些)。它们的行尾因文件而异，文件本身的行尾也不同，尽管我怀疑它们中的大多数都以 crlf 行尾存储在 git 中。
这里主要有两个问题:
1) 使用相同存储库的不同人可以查看更改，并且他们会看到一组不同的更改。有时，由于规范化的行结尾，“整个文件”已被更改。有时只有文件的一部分被更改。这似乎主要取决于 core.autocrlf 是否已设置为 true 或 false，并且似乎还受到 .gitattributes 文件的使用的影响。
2) 我希望所有人都能够将文件提交到 git 存储库，而不必痛苦地关注他们的特定 git 配置是否已设置为进行 crlf 转换，或者他们的文本编辑器、IDE 或任何工具他们决定使用。 (尽管这种行为在 Windows 上可能很糟糕，但我们需要忍受它......)
主要问题是:我如何确保“gitk”、“git diff”、“git show”等显示的输出与显示的更改完全一致。我不太关心这里的行结尾，而是更关心确保给定提交的“更改”与所有开发人员所看到的更改相同。我不希望一个人看到一个变化，看到“所有的行都变了”(即行尾都变了)，而另一个人看到同样的变化，说:“三行都变了”。
- 注意:有些人使用github查看变化。
就是说，我想知道行尾是如何处理的，所以我最终要问的是如何知道行尾会发生什么。例如，如果我在 .gitattributes 中为给定文件指定“eol=crlf”，这是否意味着该文件已使用该设置提交给 git？如果我 check out 在设置该 .gitattributes 文件之前提交的该文件的早期版本，会发生什么情况？
最佳答案
好的，这是正在发生的事情:
首先:差异看起来总是一样的，并且不依赖于本地 git 配置。你可以试试:git diff HEAD^ HEAD 在你所有的机器上看起来都一样(假设它们有相同的 HEAD)。
但是为什么差异在您的机器上看起来不同呢？假设您的存储库中有一个看起来完全像这样的文件:
two \r\n lines
checkout 在每台机器上看起来都是这样的。但是在 checkin 时有两种选择:
行尾规范化开启。该文件现在将 checkin 为:
two \n lines和
git diff将报告将要发生变化行尾规范化已关闭。该文件将 checkin 为:
two \r\n lines和
git diff不会报告任何更改。
现在，您如何确保每个人都能看到相同的变化？我建议为每个人启用行尾规范化。为此，请使用以下内容在您的存储库的根目录中创建一个 .gitattributes:
* text=auto
并将这个文件提交到每个分支。一旦每个人都 pull 了这个提交，差异将在任何地方看起来都一样。
最后说明:core.eol 对此没有任何影响。它只更改工作目录中的行结尾。 git diff 不会根据索引区分工作目录，但会根据索引区分将提交的内容。
关于windows - 写入实际的 git 存储库时使用什么行尾？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14805415/