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

Question

我不了解git中与CrLf设置相关的复杂性： core.autocrlf ， core.safecrlf

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

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

是的，我知道这个问题 ，那里的答案没有见地，因此无济于事。

Answer 1

autocrlf的三个值：

• true当内容进入存储库（已提交）时，其行尾将转换为LF，而当内容从存储库中出来（被检出）时，行尾将转换为CRLF。 通常，这是指无知的Windows用户/编辑者。 假设编辑者（或用户）将创建带有CRLF结尾的文件，并且会在看到正常的LF结尾时惊慌失措，但是您想在回购中使用LF结尾，则希望可以覆盖您。 不过，事情可能会出错。 在链接的问题中有虚假合并冲突的示例以及修改文件的报告。

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

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

请注意， autocrlf不会影响存储库中已经存在的内容。 如果您以前使用CRLF结尾来提交内容，它们将保持这种状态。 这是避免依赖autocrlf的很好理由； 如果一个用户没有设置它，他们可以将带有CRLF结尾的内容添加到存储库中，并且它会一直存在。 强制规范化的一种更强方法是使用text属性 ； 假设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 。