写入实际的git仓库时使用哪种行尾？

Question

针对一个非常庞大的代码仓库，其中存在一些不一致的换行符和文件编码格式（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中？如果我检出之前提交的那个文件版本，而当时还没有设置.gitattributes文件，会发生什么呢？

- Arafangion

Answer 1

好的，这是正在发生的事情：

首先：差异始终相同，不依赖于本地git配置。您可以尝试一下：git diff HEAD^ HEAD在所有机器上看起来都是一样的（假设它们有相同的HEAD）。

但是为什么差异在您的机器上看起来不同呢？假设您的存储库中有一个文件，看起来完全像这样：

two \r\n lines

在每台机器上，已检出的内容看起来都是相同的。但在检入时有两个选项：

1. Line ending normalization is on. The file will now be checked in as:

   two \n lines
   

   and git diff will report that there is going to be a change

2. Line ending normalization is off. The file will be checked in as:

   two \r\n lines
   

   and git diff will not report any changes.

---

现在，如何确保每个人看到的更改都是相同的呢？我建议为所有人启用行结束标准化。为此，请在您的存储库根目录中创建一个.gitattributes文件，并添加以下内容：

*   text=auto

将此文件提交到每个分支。一旦每个人都拉取了这个提交，差异将在任何地方看起来都是相同的。

---

最后注意： core.eol 对此没有任何影响。它只改变工作目录中的行尾。 git diff 不会将工作目录与索引进行比较，而是将即将提交的内容与索引进行比较。

- Chronial

---

太好了！这解释了每种情况，实际上正是我所经历的情况。 - Arafangion

Answer 2

我假设你会谷歌“git换行符”以了解基本的仓库设置。

你无法影响已提交的任何内容。你唯一能做的就是创建新的提交，其中包含任何你喜欢的修复后的文件内容。

根据你下面的评论，你想要完全忽略换行符差异。请参见这里和这里，这是我能找到的最好的之前的stackoverflow答案。

- jthill

---

jthill：我不想看到之前在存储库中被视为“autocrlf=true”的文件突然被认为在已经提交的提交中每一行都发生了更改。似乎每当一个文件以crlf（使用autocrlf=false）存储在git中时，报告的差异可能会随着.gitattribute更改而变化（当文件现在是eol=crlf vs eol=lf时）。 （但我可能误解了迹象） - Arafangion

我（显然）不知道关于重置的事情，我从我的答案中删除了那行。但是看起来你已经研究了如何处理粗心提交的问题，你想让git完全忽略任何行尾不一致吗？ - jthill

理想情况下是可以的，但我的首要关注点是了解为什么不同用户根据其autocrlf设置看到明显固定的历史提交的输出不同，然后为所有未来的提交修复它。如果历史提交也忽略行尾不一致性或至少规范化，那就更好了。请注意，带BOM的UTF-8文件是一个复杂的问题。 - Arafangion

让我重新措辞我的问题 - 我现在已经能够理解发生了什么，所以我应该能够澄清这个问题。当我写这个问题时，我并不真正知道'eol=crlf'是什么意思，但我知道我希望所有的“文本”文件更改都能被任何人一致地查看，而不受他们本地git配置的影响。 - Arafangion

提供赏金（注意：目前只有我点赞了）。 :) - Arafangion