在Windows上使用Git：crlf设置是什么意思？

Question

在Windows上使用Git：crlf设置是什么意思？

windowslinuxgitnewlinecore.autocrlf

82

我不理解与 git 相关的 CrLf 设置复杂性: core.autocrlf，core.safecrlf

我正在团队中开发一个跨平台项目，希望 Windows 和 Linux 开发人员能够一起工作，而不会因为行尾样式的不同而被 git 标记为已修改。

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

是的，我知道这个问题，那里的答案并没有给出深入的见解，因此不太有用。

- Jonathan Livni

其他相关问题：https://dev59.com/Y3I-5IYBdhLWcg3wF0Uc和https://dev59.com/lHM_5IYBdhLWcg3wvF3J - Cascabel

自动crlf的副作用示例：https://dev59.com/hnI-5IYBdhLWcg3wF0Uc - VonC

1

只是为了让你感到更舒适：没有人完全做到 :) - eckes

3个回答

13

我探索了三种可能的提交和检出情况，这是得出的表格：

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ 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的文件则保持原样。

- pratt

2

你在Windows电脑还是Unix电脑上进行这些实验的？ - Edward Falk

1

@EdwardFalk，core.autocrlf的行为不取决于操作系统类型。但如果我没记错，在Windows上的默认值是true，而在Linux上则是input。还有一件可能会导致问题的事情是，大多数Windows上的IDE默认配置为使用CRLF来创建新文件，而在Linux上则是LF。 - pratt

我认为你在input和true之间搞反了。Srikanth Popuri下面的表格看起来对我来说是正确的。 - Gandalf Saxe

@GandalfSaxe 看起来你是对的。让我来修复它。 - pratt

4

顺便说一下，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之间的差异。以下是基于操作系统平台的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。

- Srikanth Popuri

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Cascabel · Accepted Answer

autocrlf有三个值：

true - 当内容进入仓库（提交）时，其换行符将被转换为LF，在内容从仓库中提取（检出）时，换行符将被转换为CRLF。这通常是为不熟悉的Windows用户/编辑器设计的。假设编辑器（或用户）将创建具有CRLF换行符的文件，并且如果看到普通的LF换行符，会感到困惑，但您希望在仓库中使用LF换行符，那么这将有所帮助。但可能会出现问题。有关于链接问题中的虚假合并冲突和修改文件的报告。
input - 当内容进入仓库时，其换行符将被转换为LF，但内容在提取时不会更改。这基本上与true在同一领域，但假设编辑器实际上可以正确处理LF换行符；您只是防止意外创建具有CRLF换行符的文件。
false - git根本不处理换行符。这取决于你。这是许多人推荐的。使用此设置时，如果文件的换行符将被破坏，您必须了解它，因此合并冲突的可能性要小得多（假设用户有知识）。教育开发人员如何使用他们的编辑器/IDE可以解决这个问题。我看到的所有为程序员设计的编辑器都能够正确处理此设置，如果进行适当配置。

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

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

我没有处理 Windows 问题和 git 的丰富经验，因此有关影响/陷阱的反馈肯定是受欢迎的。