为什么我的 .gitattributes 文件没有阻止在 Windows 上签出文件时添加“\r”？答案

【问题标题】：Why isn't my .gitattributes file preventing the addition of "\r"s when checking out files on Windows?为什么我的 .gitattributes 文件没有阻止在 Windows 上签出文件时添加“\r”？
【发布时间】：2020-09-27 19:22:49
【问题描述】：

我在 Windows 10 上的 Cygwin shell 中使用 Git 版本 2.28.0.windows.1。在我克隆我的存储库后，我可以看到这个

$ cat .gitattributes 
* text=auto
*.sh text eol=lf

我认为它会纠正错误的行尾（我想消除自动包含的“\r”行尾）。但是，在我克隆之后

git clone https://github.com/chicommons/maps.git
cd maps

我仍然可以看到我不想要的行尾......

$ grep '\r' web/entrypoint.sh
python manage.py migrate
python manage.py migrate directory
python manage.py docker_init_db_data

我可以用我的“.gitattributes”（或者可能是另一个文件？）做什么来防止这些行尾出现？

【问题讨论】：

使用标准 git 配置有什么问题吗？ git config --global core.autocrlf input 将在结帐时为您提供 LF。

标签： git windows-10 line-endings gitattributes

【解决方案1】：

eol=lf 指令将阻止 Git 添加回车，但不会阻止 Git保留现有的回车。

真正理解这里发生的事情需要一点关于 Git 如何在提交中存储文件的知识。关键是：

每次提交都以只读、压缩、仅 Git 和去重的格式存储每个文件的完整快照。这意味着您实际看到和处理/使用的文件不是 in 存储库：您使用的文件在您的 working tree 或 work-tree。
任何提交的所有部分，包括它的所有文件，实际上都是不可更改的。如果您从存储库中取出一个 Git 内部对象（包括提交），以某种方式对其进行修改，然后将其放回去，您并没有更改 original; 相反，您只是添加了 另一个，这个新的得到一个不同的哈希ID。
要从提交中获取文件到您的工作树中，Git 必须将它们复制出来。这很明显；不明显的是每个文件都有第三个“副本”。第三个（实际上是中间）副本存在于 Git 所谓的 index 或 暂存区 中，或者（现在很少见）缓存。这三个名称都指同一个实体。

也就是说，假设HEAD 附加到分支名称master 和master 当前表示其哈希ID 为a123456... 的提交。换句话说，这个带有丑陋哈希 ID 的提交是你的当前提交。在这个提交中，我们有名为 README.md 和 main.py 的文件，在你的情况下是 web/migrate.sh。该文件有三个“副本”。这里的“副本”用引号引起来，因为其中两个是自动去重的格式，所以实际上只有一个底层副本。

我们可以在一张表中说明这三个副本，使用特殊名称HEAD 来指代提交a123456...（当前提交）：

    HEAD              index           work-tree
--------------    --------------    --------------
README.md         README.md         README.md
main.py           main.py           main.py
web/migrate.sh    web/migrate.sh    web/migrate.sh

这些文件是从哪里来的？好吧，当您第一次克隆存储库时，您的 Git 会从其他 Git 获取所有提交。这些提交在每个 Git 中完全相同，并且在每个 Git 中具有相同的哈希 ID。然后，您的 Git 将其中一个提交（您正在签出的提交）复制到您的 Git 索引，并将文件从其索引复制到您的工作树。这样就可以得到每个文件的三个副本。

工作树文件是普通的日常文件，您可以使用计算机上的任何程序对其进行读写。其他文件不是。当（或之后）您对其中一个文件的工作树副本完成一些工作时，您可以在其上运行git add。原因是git add 告诉 Git：使索引副本与工作树副本匹配。因此，如果您更改了main.py，例如，索引中main.py 的版本现在与存储库中main.py 的版本不同：

    HEAD              index           work-tree
--------------    --------------    --------------
README.md(1)      README.md(1)      README.md
main.py(1)        main.py(2)        main.py
web/migrate.sh(1) web/migrate.sh(1) web/migrate.sh

提交中的副本实际上是不可更改的，因此HEAD（目前是commit a123456... 的缩写）始终包含这三个版本的文件。但是该索引虽然使用内部格式，但它不是提交¹ 并且不是只读的。所以git add 可以替换索引副本。

(运行 git commit 获取索引中的任何内容并使用它来进行新的提交。然后新的提交成为当前的提交，因此 name HEAD 和当前的分支名称，现在参考 new 提交，而不是提交 a123456...。但我们还不需要走那么远。）

¹它是什么，有点复杂，但大致而言，您可以将索引视为保存您的建议的下一次提交时间>。每次你签出某个提交时，Git 必须设置索引以准备下一个提交：通常，通过从你刚刚签出的提交中填写它。

从索引复制或复制到索引是 Git 调整行尾的时候

Git 索引中的文件副本采用压缩的、仅限 Git 的、去重复的格式。工作树中文件的副本是普通的日常计算机格式。因此，任何时候 Git 将从 Git 的索引复制到您的工作树，它都必须扩展文件；并且任何时候 Git 将您的工作树从复制到其索引到，它必须压缩和去重文件。

此复制过程是对文件进行任何更改的理想时机。所以这就是.gitattributes 和行尾的东西发挥作用的地方。假设文件 in 通过存储库中的索引到达那里，具有换行符终止的行，只有\n。假设您希望文件的 work-tree 副本具有 \r\n 或 CRLF 行结尾。

如果 Git 在索引的途中将 \n 变成 \r\n，并在到索引，这可以实现您的目标。这就是* text eol=crlf 会做的事情。

但如果你不想这样呢？如果您希望\n 结尾保持\n 结尾怎么办？这就是* text eol=lf 会做的事情。 \n 结尾如何保持\n 结尾？ 不做任何改变。

所以* text eol=lf 表示不要进行更改。但是，如果存储库中的文件（因此被复制到索引中）有 \r\n (CRLF) 行结尾怎么办？那么，你的工作树文件也是如此。

要使 存储库 中的某些文件具有 \n-only 行尾，您需要：

从工作树副本中删除 \r；
git add 生成的文件；和
git commit 进行新的提交。

然后可以将此新提交分发到此存储库的所有其他副本，并用于代替这些文件具有 \r\n (CRLF) 结尾的现有（错误）提交。

请注意，错误提交将继续存在：这就是修订控制的全部意义所在。我们不会消除坏的，因为其他人也有它们，我们要记住他们使用的是坏的。

现在，如果没有其他人拥有此存储库的副本，或者提交错误，那么我们处于特殊情况。在这种情况下，我们可以放弃错误的提交，转而使用新的和改进的提交。（具体如何在 Git 中做到这一点是另一个答案的主题。）但一般来说，我们只是添加一个修复，并保留原来的。

【讨论】：

【解决方案2】：

grep 在其搜索模式中不做 C 语言转义，它有一个非常有限的集合。您会在这些行中找到文字 rs。

尝试grep $'\r' web/entrypoint.sh 了解最新情况，或尝试grep --color=always '\r' web/entrypoint.sh。

完全披露：我已经很久没有绊倒我了，我也忘记了，我不得不在灯泡亮起之前打败它。

【讨论】：