使用 `.gitattributes` 文件修复 Git 存储库中的行尾

Question

需要解决的问题：

我有一个包含单个 .md 文件的存储库，其中包含我正在写的一篇文章。

我从几台不同的计算机编辑文件，一台运行 Linux，另一台运行 Windows。

现在在 Windows 中查看git diff，我已经进行了一些更改，我可以看到我的文章显示为很好地分开的文本行......所有即将被删除并被一个长行替换，其中是段落以^Ms 分隔。

我知道^M 指的是 Windows 的 CLRF 行结尾。

diff 结果表明我在 Linux 中启动了该文件（完全有可能；我不记得了），然后将其保存在 Windows 中，并且所有行尾都已被替换。

我希望能够在两个操作系统中打开文件，并按应有的方式显示行，并有一个 diff 结果显示换行符（而不是 ^M 占位符）并且只更改实际内容。

我尝试过的：

我已经完成了一些background reading，阅读了nice overview 的行尾和Git 设置，甚至尝试按照another Stack Overflow question 中的命令进行操作。

就目前而言，我在存储库的顶层有一个.gitattributes 文件，我已将其提交给存储库本身。它只包含两行：

# These files are text and should be normalised (convert Windows' CLRF to LF)
*.md text

我已经试过了（source）：

git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"

还有这个（source）：

git rm --cached -r .
git config core.autocrlf input
git diff --cached --name-only -z | xargs -0 git add
git commit -m "Fixed crlf issue"

在第二种情况下，最后一个命令告诉我没有什么要提交的。 （我也不喜欢更改core.autoclrf 的想法，因为我试图完全通过.gitattributes 来做这件事，但我感到很沮丧。）

很高兴回答问题并提供更多详细信息。有什么想法我可能会出错吗？我错过了一步吗？

Answer 1

尝试使用

*.md text eol=native

而不是

*.md text

在你的 .git 属性中。

我确实设置了一个包含 CR-LF 文件的小型测试存储库，并按照您的第一个程序执行规范化：

git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"

签入时正确规范化的文件。 但是，奇怪的是，即使我在 OSX 上，它在结帐时仍然保持 CR-LF。

据说，core.eol 的默认值是原生的。所以，我希望 git 只使用 LF 来检查我的文件。但似乎出于某种原因，它只是没有这样做。 所以，我对 .gitattributes 的理解是有缺陷的，或者我们有一个 bug 需要提交到 git...

无论如何，正如我所说，在 .gitattributes 中显式设置 eol=native 对我有用。