的三个值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的大量经验，因此当然欢迎您提供有关含义/陷阱的反馈。