有时候我们会遇到这样的情况
$ git add .
warning: LF will be replaced by CRLF in xxx.
The file will have its original line endings in your working directory
分析
从字面意思上来看:警告:在gitee_handsome8_0.php中,LF将被CRLF替换。
该文件将在您的工作目录中具有其原始行结尾。显然,问题出在不同操作系统所使用的换行符是不一样的,一般有两种情况会导致这个问题:
我们的团队成员是Linux/Mac平台并参与了项目的git提交
Windows平台的某些软件会生成换行是LF的代码文本(比如Webstorm等)
相关信息
Uinx/Linux采用换行符LF表示下一行(LF:LineFeed,中文意思是换行,即“\n”)
Dos和Windows采用回车+换行CRLF表示下一行(CRLF:CarriageReturn LineFeed,中文意思是回车换行即“\r\n”)
Mac OS只使用换行(LF)一个字符来结束一行,早期的Mac OS采用回车CR表示下一行(CR:CarriageReturn,中文意思是回车,后来Mac也投奔了unix)
git处理换行
在Git中,可以通过以下命令来显示/设置当前你的Git中采取哪种对待换行符的方式
git config core.autocrlf ture/false/input
当设置成true时,这意味着你在任何时候添加(add)文件到git仓库时,git都会视为它是一个文本文件(text file)。它将把crlf变成LF。
当设置成false时,git将不做转换操作。文本文件保持原来的样子。
设置为input时,添加文件git仓库时,git把crlf变成lf。当有人Check代码时还是lf换行格式。因此在window操作系统下,不要使用这个设置。
解决办法
1.如果你目前是Window平台并出现该警告,什么也不用做,虽然这个警告难看,但这个警告能保证项目团队正常跨系统git操作代码
因为git的Windows 客户端基本都会默认设置
core.autocrlf=true
(可通过git config core.autocrlf
命令查询Windows上该属性是否默认true。如不是true,通过config --global core.autocrlf true
命令设置该属性为true),而core.autocrlf=true
有以下3个功能来避免出错:在
git add
时,Git自动把LF转换成CRLF,并给出那条警告 LF will be replaced by CRLF在
git commit
时,Git自动把CRLF转换成LF在
git checkout/switch
或git clone
时,Git自动把LF转换成CRLF
2.如果我们是Linux 或 Mac平台,是不需要“在git checkout/switch
或git clone
时,Git自动把LF转换成CRLF”的。然而当一个CRLF作为行结束符的文件在Linux 或 Mac平台不小心被引入时,你肯定想让 Git 修正。 所以,你可以通过config --global core.autocrlf input
命令把 core.autocrlf 设置成 input 来告诉 Git 在commit时把CRLF转换成LF,但git checkout时不转换
通过上面两个方案,在 Windows 上的checkout文件中会保留CRLF,而在 Mac 和 Linux 上,以及版本库中会保留LF,从而保证项目团队正常跨系统git操作代码。
注意
为什么要注意这个问题呢,因为此问题有一些负面影响:
假如你正在Windows上写程序,又或者你正在和其他人合作,他们在Windows上编程,而你却在其他系统上,在这些情况下,你可能会遇到行尾结束符问题。此问题的全部负面影响如下:
一个最直接后果就是,Unix/Mac系统下的一个多行文本文件在Windows里打开的话,多行文本会变成一行。(原因:Unix/Mac换行只用了换行符‘\n’,而Windows的换行要求是回车换行符‘\r\n’,因此Unix/Mac中的“多行文本”的换行不符合Windows的规则,所以Windows对这些不符合换行规则的多行文本全部按照没有换行处理,所以导致多行文本会变成一行)
而Windows里的文件在Unix/Mac下打开的话,在每行的结尾可能会多出一个^M符号
Linux保存的文件在windows上用记事本看的话会出现黑点