LF将被git中的CRLF取代 – 这是什么，它是重要的？
可能重复：
用CRLF代替LF
当我创build一个新的rails应用程序时，我在git中看到一个关于LFreplace的警告。 我做的git init git add。
然后繁荣！ 我看到这几乎所有的文件popup。 我通常只是继续前进，并build立我的应用程序，并在文件的许多更改后消失。
例：
该文件的原始行结束在您的工作目录中。 警告：LF将被Gemfile中的CRLFreplace。
该文件的原始行结束在您的工作目录中。 警告：LF将被Gemfile.lock中的CRLF所取代。
该文件的原始行结束在您的工作目录中。 警告：在README中，LF将被CRLF取代。
LF和CRLF有什么区别？
我应该从长远的angular度来关心这个问题，还是忽略它，像往常一样继续下去？
在Unix系统中，行的结尾用换行符（LF）表示。 在窗口中，一行用回车符（CR）和换行符（LF）（CRLF）表示。 当你从一个unix系统上传的git获得代码时，他们只会有一个LF。
如果你想closures这个警告，请在git命令行中input
git config core.autocrlf true
如果你想做一个聪明的决定git应该如何处理这个， 请阅读文档
这是一个片段
格式和空白
格式化和空白问题是许多开发人员在协作时遇到的更令人沮丧和微妙的问题，特别是跨平台问题。 修补程序或其他协作工作非常容易引入微妙的空白变化，因为编辑器会默默地引入这些修改，而且如果您的文件触及Windows系统，则可能会replace它们的行尾。 Git有几个configuration选项来帮助解决这些问题。
core.autocrlf如果你在Windows上进行编程，并与不是的人（反之亦然）合作，你可能会碰到一些结束语的问题。 这是因为Windows在其文件中为换行符使用回车符和换行符，而Mac和Linux系统只使用换行符。 这是跨平台工作的一个微妙但令人难以置信的烦人的事实; Windows上的许多编辑器默默地用CRLF代替现有的LF风格的行结尾，或者当用户点击回车键时插入两个行尾字符。
Git可以通过将CRLF行结束符自动转换为LF来处理这种情况，当您将文件添加到索引时，反之亦然，当它将代码检出到文件系统上时。 您可以使用core.autocrlf设置打开此function。 如果您在Windows机器上，请将其设置为true – 在签出代码时，将LF结尾转换为CRLF：
$ git config --global core.autocrlf true如果您使用的是使用LF换行符的Linux或Mac系统，那么当您签出文件时，您不希望Git自动转换它们; 但是，如果一个带有CRLF结尾的文件被意外地引入，那么你可能希望Git来修复它。 你可以告诉Git在提交时将CRLF转换为LF，而不是通过设置core.autocrlf来input：
$ git config --global core.autocrlf input这个设置应该让你在CRLF结尾在Windows结账，但LF结尾在Mac和Linux系统和存储库。
如果你是一个Windows程序员做一个纯Windows项目，那么你可以closures这个function，通过设置configuration值为false来logging仓库中的回车符：
$ git config --global core.autocrlf false
如果你愿意，你可以在你的git核心configuration中使用这个function来取消激活
git config core.autocrlf false
但是，最好是摆脱使用警告
git config core.autocrlf true
