为什么我应该在 Git 中使用 core.autocrlf=true？

Question

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

1. 在任何地方将core.autocrlf 设置为false，

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

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

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

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

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

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

Answer 1

在我们的项目中，我们声明了将 autocrlf 设置为 input 值的必要性。这就是您可能对此感兴趣的原因：

• 您的项目在 Linux/Unix 环境中运行，开发人员正在 Windows 中编写代码。在推送过程中，CRLF 会自动转换为 LF，因此您只需在 Unix 服务器上签出 Git repo，一切都会很好。
• 有时开发人员使用 WinSCP 手动将配置从 Windows 机器上传到服务器。这会导致 Unix 机器上的 CRLF 行结束和应用程序启动失败。 “输入”值部分消除了此类情况的数量

我们不久前面临的问题：

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

Answer 2

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

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

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

Answer 3

我在 GitHub 上工作，我发现 this article 很有帮助。

它描述了 git autocrlf 的配置和设置 .gitattributes 文件。

Answer 4

对我来说。

编辑 .gitattributes 文件。

添加

*.dll binary

然后一切顺利。

Answer 5

更新 2：

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

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

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

更新：

注意：正如 VonC 所述，从 Git 2.8 开始，合并标记 will not introduce Unix-style line-endings to a Windows-style file。

原创：

我注意到此设置的一个小问题是，当存在合并冲突时，git 添加的用于标记差异的行 not 具有 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 6

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

• 避免 git status 将所有文件显示为 modified，因为在将基于 Unix 的 EOL Git 存储库克隆到 Windows 时会自动进行 EOL 转换（例如，请参阅 issue 83）
• 和您的编码工具以某种方式依赖于您的文件中存在的 native EOL 样式：
  • 例如，用于检测本地 EOL 的硬编码代码生成器
  • 具有正则表达式或代码集以检测本机 EOL 的其他外部批处理（您的存储库外部）
  • 我相信某些 Eclipse 插件可以生成带有 CRLF 的文件，而不管平台如何，这可能是个问题。
  • 您使用 Notepad.exe (unless you are using a Windows 10 2018.09+, where Notepad respects the EOL character detected) 进行编码。

除非您可以看到必须处理原生 EOL 的特定处理，否则您最好使用leaving autocrlf to false (git config --global core.autocrlf false)。

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

如果您希望克隆该存储库的所有用户都使用相同的配置，请查看“What's the best CRLF handling strategy with git?”，使用.gitattributes file 中的text 属性。

例子：

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

---

注意：从 git 2.8（2016 年 3 月）开始，合并标记将不再在 CRLF 文件中引入混合行结尾 (LF)。
见“Make Git use CRLF on its “<<<<<<< HEAD” merge lines”