warning: LF will be replaced by CRLF的解决方法

问题描述：使用git add 命令添加文件到暂存区的时候，出现：

warning: LF will be replaced by CRLF

译：LF将被CRLF取代

原因分析：

CRLF ：Carriage-Return Line-Feed == 回车换行

回车(CR, ASCII 13, \r)

换行(LF, ASCII 10, \n)

这两个ACSII字符不会在屏幕有任何输出，但在Windows中广泛使用来标识一行的结束，而在Linux/UNIX系统中只有换行符。也就是说在windows中的换行符为 CRLF， 而在linux下的换行符为：LF；使用git来生成一个工程后，文件中的换行符为LF，当执行git add .时，系统提示：LF 将被转换成 CRLF。

解决方法：

1、删除刚刚生成的.git文件：rm -rf .git

2、git config --gobal core.autocrlf false

为什么要加这句话的解释：https://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf

原文：

Git has three modes of how it treats line endings:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

You can set the mode to use by adding an additional parameter of true or false to the above command line.

If core.autocrlf is set to true, that means that any time you add a file to the git repo that git thinks is a text file, it will turn all CRLF line endings to just LF before it stores it in the commit. Whenever you git checkout something, all text files automatically will have their LF line endings converted to CRLF endings. This allows development of a project across platforms that use different line-ending styles without commits being very noisy because each editor changes the line ending style as the line ending style is always consistently LF.

The side-effect of this convenient conversion, and this is what the warning you're seeing is about, is that if a text file you authored originally had LF endings instead of CRLF, it will be stored with LF as usual, but when checked out later it will have CRLF endings. For normal text files this is usually just fine. The warning is a "for your information" in this case, but in case git incorrectly assesses a binary file to be a text file, it is an important warning because git would then be corrupting your binary file.

If core.autocrlf is set to false, no line-ending conversion is ever performed, so text files are checked in as-is. This usually works ok, as long as all your developers are either on Linux or all on Windows. But in my experience I still tend to get text files with mixed line endings that end up causing problems.

My personal preference is to leave the setting turned ON, as a Windows developer.

See http://kernel.org/pub/software/scm/git/docs/git-config.html for updated info that includes the "input" value.

译文：

关于行尾，Git有三种处理它的模式：

$ git config core.autocrlf

# that command will print "true" or "false" or "input"

你可以通过在以上命令行尾添加一个额外的参数“true”或“false”来设置模式。

如果core.autocrlf设置为true，那意味着任何时候你添加一个文件到git repo，git都将认为它是一个文本文件，在git保存提交该文件之前将以LF转换所有以CRLF结尾的行。（以至于）无论什么时候，你git checkout任何东西，所有的文本文件自动将其CRLF结尾的行转换为LF结尾。这允许跨平台开发一个项目，不会因使用（不同的）行尾样式而错乱不堪。因为每个编辑器总是将LF结尾的样式转为一致的行尾样式。

这方便的转换有个副作用正如你所看到的警告一样，如果一个你原本以LF代替CRLF结尾编写的文本文件，它通常将以LF结尾的形式保存起来，但过一会儿再次查看的时候，它将以CRLF结尾。对于一般的文本文件这通常没啥大问题。在这种情况下，这种警告是一种“（仅）针对你的信息”，但万一git错误地认定一个二进制文件为文本文件的话，这就是一个严重的警告了，因为git将会破坏你的二进制文件。

如果core.autocrlf设置为false，则行尾永远不会执行转化。因此，文本文件都将以这样的方式写入。这通常都可以正常运行，只要你所有的开发者要不都在Linux下开发，要不都在Windows下开发。但在我的实际经历中我仍然趋向于让文本文件带有混合样式的行尾来解决造成的问题。

作为一名Windows的开发者，我个人偏向于将设置打开。

See http://kernel.org/pub/software/scm/git/docs/git-config.html for updated info that includes the "input" value.

# 通过百度翻译的译文我觉得不怎么好，上文是我自己翻译的，如果有误，请及时指出。

3、重建：git init

4、git add 系统正常运行

注意：以下是廖雪峰老师原话

千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。建议你下载Notepad++代替记事本，不但功能强大，而且免费！记得把Notepad++的默认编码设置为UTF-8 without BOM即可。