Windows 上的 Git：crlf 设置是什么意思？

Question

我不明白 git 中与 CrLf 设置相关的复杂性：core.autocrlf、core.safecrlf

我正在团队中开发一个跨平台项目，并且希望 Windows 和 Linux 开发人员能够一起工作，而无需 git 将文件标记为仅因为行结束样式而修改。

各种设置是什么意思？选择任何选项会有什么后果？对于我的情况，最好的解决方案是什么？

是的，我知道 this question 并且那里的答案没有洞察力，因此没有帮助。

Answer 1

autocrlf 的三个值：

• true - 当内容进入存储库（已提交）时，其行尾将转换为 LF，而当内容从存储库出来（已签出）时，行尾将转换为CRLF。这通常适用于无知的 Windows 用户/编辑器。假设编辑器（或用户）将创建带有 CRLF 结尾的文件，并且如果它看到正常的 LF 结尾会吓坏，但是您希望在 repo 中使用 LF 结尾，这有望覆盖您。不过，事情可能会出错。链接问题中有虚假合并冲突的示例和修改文件的报告。

• input - 当内容进入存储库时，其行尾将被转换为 LF，但内容在输出时保持不变。这与true 基本处于同一领域，假设编辑器实际上可以正确处理LF 结尾；您只是在防止意外创建带有 CRLF 结尾的文件的可能性。

• false - git 根本不处理行尾。由你决定。这是很多人推荐的。使用此设置，如果文件的行尾将被弄乱，您必须意识到这一点，因此合并冲突的可能性要小得多（假设知情用户）。教育开发人员如何使用他们的编辑器/IDE 几乎可以解决这个问题。如果配置正确，我见过的所有为程序员设计的编辑器都能够处理这个问题。

请注意，autocrlf 不会影响存储库中已经的内容。如果您之前已经提交了带有 CRLF 结尾的内容，他们将保持这种状态。这是避免依赖 autocrlf 的一个很好的理由；如果一个用户没有设置它，他们可以将带有 CRLF 结尾的内容放入 repo，它会一直存在。强制标准化的一种更强大的方法是使用text attribute；假设 git 决定内容是文本（不是二进制），将给定路径设置为 auto 会将其标记为行尾规范化。

一个相关的选项是safecrlf，它基本上只是一种确保您不会对二进制文件执行不可逆转的 CRLF 转换的方法。

我在处理 Windows 问题和 git 方面没有大量经验，因此当然欢迎提供有关影响/陷阱的反馈。

Answer 2

我探索了提交和签出案例的 3 个可能值，这是结果表：

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

我建议在所有平台上使用core.autocrlf = input。在这种情况下，如果 Git 面对 CRLF，它会隐式将其转换为 LF，而现有的带有 LF 的文件将保持原样。

Answer 3

仅供参考，默认情况下，以 Windows 结尾的行将采用 CRLF，Linux 将采用 LF。 请参阅下表以便清楚了解。

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║    false     ║    input     ║    true      ║
║               ║ Win => Unix  ║ Win => Unix  ║ Win => Unix  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ *CRLF => LF  ║ *CRLF => LF  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ *LF => CRLF  ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

在上述表格信息中，符号 * 突出显示了 Windows 和 Unix 之间的差异。一目了然，以下是基于 OS 平台的 CLRF 信息：

---

对于 Windows 用户

• 如果 Windows 用户处理跨平台项目，必须对于 Windows 机器为core.autocrlf=true，对于 Unix 机器为core.autocrlf=input。
• 如果 Windows 用户只使用 Windows 项目，它可以是 core.autocrlf=true 或 core.autocrlf=false。但是core.autocrlf=input 在这种情况下会导致问题。

---

适用于 Unix 用户（Linux / Mac OS）

• 如果 Unix 用户处理跨平台项目，则必须对于 Windows 机器为 core.autocrlf=true，对于 Unix 机器为 core.autocrlf=input。
• 如果 Unix 用户只使用 Unix 项目，它可以是 core.autocrlf=input 或 core.autocrlf=false。但是core.autocrlf=true 在这种情况下会导致问题。

---

对于相同的操作系统用户

• 对于纯Windows项目或纯Unix项目，可以是core.autocrlf=false。