我不理解git中与CrLf设置相关的复杂性：core.autocrlf，core.safecrlf
我正在团队中开发一个跨平台项目，并且希望Windows和Linux开发人员能够在没有git标记文件的情况下协同工作，因为行结束样式。
各种设置意味着什么？选择任何选项会产生什么后果？那对我的案子来说最好的解决办法是什么？
是的，我知道this question并且答案没有洞察力，因此没有帮助。
答案 0 :(得分：94)
autocrlf的三个值：
true - 当内容进入存储库（已提交）时，其行结尾将转换为LF，当内容从存储库中出来时（已签出），行结尾为转换为CRLF。这通常意味着无知的Windows用户/编辑。假设编辑器（或用户）要创建具有CRLF结尾的文件，并且如果它看到正常的LF结尾会变得惊慌失措，但是你想在回购中找到LF结尾，这将有希望覆盖你。但是，事情可能会出错。在链接的问题中存在虚假合并冲突和修改文件报告的示例。
input - 当内容进入存储库时，其行结尾将转换为LF，但内容在出路时保持不变。这基本上与true处于同一领域，假设编辑者实际上可以正确处理LF结尾;你只是想防止意外创建一个带有CRLF结尾的文件。
false - git根本不处理行结尾。由你决定。这是很多人推荐的。使用此设置，如果文件的行结尾将被弄乱，您将必须意识到它，因此合并冲突的可能性要小得多（假设知情用户）。教育开发人员如何使用他们的编辑器/ IDE几乎可以解决这个问题。我见过为程序员设计的所有编辑器都能够正确配置它。
请注意，autocrlf不会影响存储库中已的内容。如果您之前已经使用过CRLF结尾，那么他们就会保持这种状态。这是避免依赖autocrlf的一个很好的理由;如果一个用户没有设置它，他们可以将CRLF结尾的内容放入回购中，并且它会坚持下去。强制规范化的一种更强有力的方法是使用text attribute;将它设置为给定路径的auto将标记为行尾标准化，假设git决定内容是文本（非二进制）。
相关选项是safecrlf，这基本上只是一种确保您不会在二进制文件上不可逆转地执行CRLF转换的方法。
我没有很多处理Windows问题和git的经验，因此对于影响/陷阱的反馈肯定是受欢迎的。
答案 1 :(得分：9)
我为提交和签出案例探索了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的现有文件保持原样。
答案 2 :(得分：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之间的差异。一目了然，下面是基于操作系统平台的CLRF信息：
core.autocrlf=true，对于Unix计算机为core.autocrlf=input。core.autocrlf=true或core.autocrlf=false。但是core.autocrlf=input会在这种情况下导致问题。core.autocrlf=true而对于Unix机器来说是core.autocrlf=input。core.autocrlf=input或core.autocrlf=false。但是core.autocrlf=true会在这种情况下导致问题。core.autocrlf=false。