为什么要在 Git 中使用 core.autocrlf=true ？

Question

我有一个可以从 Windows 和 OS X 访问的 Git 存储库，并且我知道它已经包含一些带有 CRLF 行结尾的文件。据我所知，有两种方法可以解决这个问题：

1. 将core.autocrlf设置为false，

2. 按照说明操作此处（在 GitHub 的帮助页面上回显）将存储库转换为仅包含 LF 行结尾，然后设置 core.autocrlf 在 Windows 上为 true，在 OS X 上为 input。这样做的问题是，如果我在存储库中有任何二进制文件：

   1. 在 gitattributes 中未正确标记为二进制，并且
   2. 恰好同时包含 CRLF 和 LF，

   它们将会被损坏。我的存储库可能包含此类文件。

那么为什么我不应该关闭 Git 的行结束转换呢？网络上有很多关于关闭 core.autocrlf 会导致问题的模糊警告，但很少有具体的警告；到目前为止我发现的唯一问题是 kdiff3 无法处理 CRLF 结尾（对我来说不是问题），并且某些文本编辑器存在行结束问题（对我来说也不是问题）。

该存储库是我公司内部的，因此我无需担心与具有不同 autocrlf 设置或行结束要求的人员共享它。

只保留行结尾是否还有我不知道的其他问题？

Answer 1

将 autocrlf 设置为 true 的唯一具体原因是：

• 避免 git status 将所有文件显示为已修改，因为将基于 Unix 的 EOL Git 存储库克隆到 Windows 存储库时完成的自动 EOL 转换（请参阅 issue 83）
• 并且您的编码工具在某种程度上取决于本机 EOL文件中存在的样式：
  • 例如，通过硬编码来检测本机 EOL 的代码生成器
  • 使用正则表达式或代码集检测本机 EOL 的其他外部批次（存储库外部）
  • 我相信某些 Eclipse 插件可以生成带有 CRLF 的文件，无论平台如何，这可能是一个问题。
  • 您使用 Notepad.exe 进行编码 (除非您使用的是 Windows 10 2018.09+，其中记事本尊重检测到的 EOL 字符）。

除非您能看到必须处理本机 EOL 的特定处理方法，否则您最好将 autocrlf 保留为 false (git config --global core.autocrlf false)。

请注意，此配置将是本地配置（因为配置不会从存储库推送到存储库）

如果您希望克隆该存储库的所有用户使用相同的配置，请查看“git 的最佳 CRLF 处理策略是什么？",使用 中的 text 属性.gitattributes 文件。

示例：

*.vcproj    text eol=crlf
*.sh        text eol=lf

---

注意：从 git 2.8（2016 年 3 月）开始，合并标记将不再在 CRLF 文件中引入混合行结尾 (LF)。
请参阅“让 Git 在其“<<<<<”

Answer 2

我是一名 .NET 开发人员，多年来一直使用 Git 和 Visual Studio。我强烈建议将行结尾设置为 true。并在存储库的生命周期内尽早执行此操作。

话虽这么说，我讨厌 Git 改变我的行结尾。源代码管理应该只保存和检索我所做的工作，而不应该修改它。曾经。但确实如此。

如果您没有将每个开发人员设置为 true，会发生什么情况，最终会有一个开发人员设置为 true。这将开始将存储库中所有文件的行结尾更改为 LF。当用户将其设置为 false 时，Visual Studio 会警告您，并要求您更改它们。你很快就会发生两件事。第一，你会收到越来越多的警告，你的团队越大，收到的警告就越多。第二，也是更糟糕的事情是，它将显示每个修改文件的每一行都已更改（因为每一行的行结尾都会被真正的人更改）。最终，您将无法再可靠地跟踪存储库中的更改。让每个人都保持真实比试图让每个人都虚假要容易和干净得多。接受您所信任的源代码控制正在做一些不应该做的事情这一事实是可怕的。曾经。

Answer 3

更新 2：

Xcode 9 似乎有一个“功能”，它将忽略文件当前的行结尾，而是在将行插入文件时仅使用默认的行结尾设置，从而导致文件带有混合行结尾。

我很确定 Xcode 7 中不存在这个错误；不确定 Xcode 8。好消息是它似乎在 Xcode 10 中得到了修复。

在它存在的时候，这个错误在我在问题中引用的代码库中引起了少量的欢闹（迄今为止使用 < code>autocrlf=false)，并导致许多“EOL”提交消息，并最终导致我编写了一个 git pre-commit 挂钩来检查/防止引入混合行结尾。

更新：

注意：正如 VonC 所指出的，从 Git 2.8 开始，合并标记将不会 将 Unix 风格的行尾引入 Windows 风格的文件。

原始：

我在这个设置中注意到的一个小问题是，当存在合并冲突时，git 添加来标记差异的行没有有 Windows 行 -结尾，即使文件的其余部分这样做，并且您最终可能会得到一个具有混合行结尾的文件，例如：

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

这不会给我们带来任何问题（我想任何可以处理这两种类型的行结尾的工具也将合理地处理混合行结尾——当然我们使用的所有行结尾都是如此），但这是需要注意的事情。

我们发现的另一件事^*是，当使用git diff查看对具有Windows行结尾的文件的更改时，已添加的行会显示其回车符返回，因此：

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* 它并不真正值得使用术语：“问题”。}

Answer 4

在我们的项目中，我们声明有必要将 autocrlf 设置为输入值。您可能对此感兴趣的原因如下：

• 您的项目在 Linux/Unix 环境中运行，开发人员在 Windows 中编写代码。在推送过程中，CRLF 会自动转换为 LF，因此您只需在 Unix 服务器上查看 Git 存储库，一切都会开箱即用。
• 有时，开发人员使用 WinSCP 手动将配置从 Windows 计算机上传到服务器。这会导致 Unix 机器上出现 CRLF 行结尾以及应用程序启动失败。 “input”值部分消除了此类情况的数量

我们不久前遇到的问题：

• 如果在 DEV 的机器上将行结尾设置为 CR（而不是 CRLF），则在推送期间它们不会转换为 LF 并且将保持 CR 状态GIT 存储库。彻底检查行尾

Answer 5

为我。

编辑 .gitattributes 文件。

添加

*.dll binary

然后一切顺利。