git config core.autocrlf false
欢迎各位兄弟 发布技术文章
这里的技术是共享的
git config core.autocrlf false
来自 https://www.cnblogs.com/zxyun/p/9617438.html
今天把项目做完之后,然后用Git准备提交代码的时候,遇到warning: LF will be replaced by CRLF警告。
当时在网上查了资料,发现很多的解决办法都是:修改git全局配置,禁止git自动将LF转化成CRLF。命令是:git config --global core.autocrlf false
.
1.LF和CRLF都是换行符,在各操作系统下,换行符是不一样的,Linux/UNIX下是LF,而Windows下是CRLF,早期的MAC OS是CR,后来的OS X在更换内核后和UNIX一样也是LF.
这种不统一确实对跨平台的文件交换带来了麻烦。虽然靠谱的文本编辑器和 IDE 都支持这几种换行符,但文件在保存时总要有一个固定的标准啊,比如跨平台协作的项目源码,到底保存为哪种风格的换行符呢?
2.Git 由大名鼎鼎的 Linus 开发,最初只可运行于 *nix 系统,因此推荐只将 UNIX 风格的换行符保存入库。但它也考虑到了跨平台协作的场景,并且提供了一个“换行符自动转换”功能。
安装好 GitHub 的 Windows 客户端之后,这个功能默认处于“自动模式”。
当你在签出文件时,Git 试图将 UNIX 换行符(LF)替换为 Windows 的换行符(CRLF);当你在提交文件时,它又试图将 CRLF 替换为 LF。
所以Git在拉取代码的时候,git会自动将代码之中与你当前系统不同的换行方式自动转换成当前系统的换行方式。
这样一来在提交代码的时候,git会认为你未修改内容的文件也认为是修改过的,然后提示你warning: LF will be replaced by CRLF这样的信息。
3.上面的解决办法固然解决了很多人的问题,但是在某些情况下就不适用。这次项目中,在用fiskit框架npm deploy打包前端文件到后端路径的时候,打包出来的文件用git进行commit的时候,提示LF和CRLF,文件的换行符被修改过,这时候也尝试了上面的方法,也没有用,最后在知乎上看到一篇文章https://www.zhihu.com/question/50862500,
如果设置core.autocrlf = false
,那么很可能会出现CRLF和LF混合的情况,这样会导致一些问题,例如git diff
失去功能,会发现很多行代码并没有修改,然而被认为是修改过了。
首先core.autocrlf = true
在windows上才是正确的选择,那么如何避免warning呢?还要有以下几个步骤:
添加.gitattributes
设置core.safecrlf = true
使用dos2unix、notepad++等工具来将LF转换成CRLF
来自 https://www.cnblogs.com/sminocence/p/9357209.html
今天用Git bash遇到的问题,看了几个回答之后发现一个比较有价值的,给大家分享一下,其他很多的回答都有很或多或少存在一些弊端。
原回答地址在stackoverflow上,附上链接--http://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf
这里我把主要的东西提炼一下翻译成中文供大家参考。
首先问题出在不同操作系统所使用的换行符是不一样的,下面罗列一下三大主流操作系统的换行符:
Uinx/Linux采用换行符LF表示下一行(LF:LineFeed,中文意思是换行);
Dos和Windows采用回车+换行CRLF表示下一行(CRLF:CarriageReturn LineFeed,中文意思是回车换行);
Mac OS采用回车CR表示下一行(CR:CarriageReturn,中文意思是回车)。
在Git中,可以通过以下命令来显示当前你的Git中采取哪种对待换行符的方式
$ git config core.autocrlf
此命令会有三个输出,“true”,“false”或者“input”
为true时,Git会将你add的所有文件视为文本问价你,将结尾的CRLF转换为LF,而checkout时会再将文件的LF格式转为CRLF格式。
为false时,line endings不做任何改变,文本文件保持其原来的样子。
为input时,add时Git会把CRLF转换为LF,而check时仍旧为LF,所以Windows操作系统不建议设置此值。
来自 https://www.cnblogs.com/keystone/p/10700520.html
windows平台下使用git add,git deploy 文件时经常出现“warning: LF will be replaced by CRLF” 的提示。 设置core.autocrlf=false,windows也用LF换行。 格式化与多余的空白字符,特别是在跨平台情况下,有时候是一个令人发指的问题。由于编辑器的不同或者文件行尾的换行符在 Windows 下被替换了,一些细微的空格变化会不经意地混入提交,造成麻烦。虽然这是小问题,但它会极大地扰乱跨平台协作。 回车符就是回到一行的开头,用符号r表示,十进制ASCII代码是13,十六进制代码为0x0D,回车(return); 换行符就是另起一行,用n符号表示,ASCII代码是10,十六制为0x0A, 换行(newline)。 所以我们平时编写文件的回车符应该确切来说叫做回车换行符。 Dos和Windows平台: 使用回车(CR)和换行(LF)两个字符来结束一行,回车+换行(CR+LF),即“\r\n”; Mac 和 Linux平台:只使用换行(LF)一个字符来结束一行,即“\n”; 最早Mac每行结尾是回车CR 即'\r',后mac os x 也投奔了 unix。 许多 Windows 上的编辑器会悄悄把行尾的换行(LF)字符转换成回车(CR)和换行(LF),或在用户按下 Enter 键时,插入回车(CR)和换行(LF)两个字符。 一个直接后果是,Unix/Mac系统下的文件在Windows里打开的话,所有文字会变成一行; 而Windows里的文件在Unix/Mac下打开的话,在每行的结尾可能会多出一个^M符号。 Linux保存的文件在windows上用记事本看的话会出现黑点。 这些问题都可以通过一定方式进行转换统一,例如,在linux下,命令unix2dos 是把linux文件格式转换成windows文件格式,命令dos2unix 是把windows格式转换成linux文件格式。 Git 可以在你提交时自动地把回车(CR)和换行(LF)转换成换行(LF),而在检出代码时把换行(LF)转换成回车(CR)和换行(LF)。 你可以用 如果使用以换行(LF)作为行结束符的 Linux 或 Mac,你不需要 Git 在检出文件时进行自动的转换。然而当一个以回车(CR)和换行(LF)作为行结束符的文件不小心被引入时,你肯定想让 Git 修正。 所以,你可以把 core.autocrlf 设置成 input 来告诉 Git 在提交时把回车和换行转换成换行,检出时不转换:(这样在 Windows 上的检出文件中会保留回车和换行,而在 Mac 和 Linux 上,以及版本库中会保留换行。) 如果你是 Windows 程序员,且正在开发仅运行在 Windows 上的项目,可以设置 false 取消此功能,把回车保留在版本库中: git 的 Windows 客户端基本都会默认设置 core.autocrlf=true,设置core.autocrlf=true, 只要保持工作区都是纯 CRLF 文件,编辑器用 CRLF 换行,就不会出现警告了; Linux 最好不要设置 core.autocrlf,因为这个配置算是为 Windows 平台定制; Windows 上设置 core.autocrlf=false,仓库里也没有配置 .gitattributes,很容易引入 CRLF 或者混合换行符(Mixed Line Endings,一个文件里既有 LF 又有CRLF)到版本库,这样就可能产生各种奇怪的问题。 http://blog.csdn.net/kxjrzyk/article/details/54944952一、发现问题
网上很多解决办法提到:
除了记事本,其他编辑器都可以正常编辑。
而没有给出具体原因和分析,现在加以补充。二、分析问题
其实,这是因为在文本处理中,CR(CarriageReturn),LF(LineFeed),CR/LF是不同操作系统上使用的换行符,具体如下:换行符‘\n’和回车符‘\r’
应用情况
影响:
三、解决问题:
情况一:
git config --global core.autocrlf true
来打开此项功能。 如果是在 Windows 系统上,把它设置成 true,这样在检出代码时,换行会被转换成回车和换行:#提交时转换为LF,检出时转换为CRLF
$ git config --global core.autocrlf true
情况二:
#提交时转换为LF,检出时不转换
$ git config --global core.autocrlf input
情况三:
#提交检出均不转换
$ git config --global core.autocrlf false
你也可以在文件提交时进行safecrlf检查
#拒绝提交包含混合换行符的文件
git config --global core.safecrlf true
#允许提交包含混合换行符的文件
git config --global core.safecrlf false
#提交包含混合换行符的文件时给出警告
git config --global core.safecrlf warn
通俗解释
http://blog.csdn.net/tskyfree/article/details/8121951
https://www.zhihu.com/question/46542168
https://www.zhihu.com/question/50862500/answer/123197258
http://www.cnblogs.com/flying_bat/p/3324769.html
来自 https://www.jianshu.com/p/450cd21b36a4
1.问题描述:windows平台下使用git add,git deploy 文件时经常出现“warning: LF will be replaced by CRLF” 的提示 2.注解: (1)换行符‘\n’和回车符‘\r’ 在计算机还没有出现之前,有一种叫做电传打字机(Teletype Model 33)的玩意,每秒钟可以打10个字符。但是它有一个问题,就是打完一行换行的时候,要用去0.2秒,正好可以打两个字符。要是在这0.2秒里面,又有新的字符传过来,那么这个字符将丢失。 于是,研制人员想了个办法解决这个问题,就是在每行后面加两个表示结束的字符。一个叫做“回车”,告诉打字机把打印头定位在左边界;另一个叫做“换行”,告诉打字机把纸向下移一行。 (A)回车符就是回到一行的开头,用符号r表示,十进制ASCII代码是13,十六进制代码为0x0D,回车(return); (B)换行符就是另起一行,用n符号表示,ASCII代码是10,十六制为0x0A, 换行(newline)。 (2)LF和CRLF区别 LF: Line Feed换行 feed v.喂养,供给;将(信息)输入 line feed直译是”将行输入”,再意译”换行” CRLF: Carriage Return Line Feed 回车换行 Carriage n.马车,火车车厢;运输费用 在carriage return中,carriage译为“车”,return译为“回” 在过去的机械打字机上有个部件叫「字车」(Typewriter carriage),每打一个字符,字车前进一格,打完一行后,我们需要让字车回到起始位置,而“Carriage Return”键最早就是这个作用,因此被直接翻译为「回车」。尽管后来回车键的作用已经不止” 倒回字车”那么简单,但这个译名一直被保留下来。 3.分析问题 这句警告出现的原因:我们在Windows平台下git add任意Windows平台编辑过的代码文本的换行默认都是CRLF,所以一般git add不会出错。但是如果如下的(i)或者(ii)发生了,那我们再进行git add这个LF换行的文件时,会出现这个警告" LF will be replaced by CRLF in …"。 (i)我们的团队成员是Linux/Mac平台并参与了项目的git提交 (ii)我们Windows平台的某些软件会生成换行是LF的代码文本(如李俊德git add的是Webstorm生成的HTML项目中隐藏文件夹.idea中的workspace.xml,这个xml文件换行是LF) (1)不同操作系统下,处理行尾结束符的方法是不同的: (A)Windows和Dos下:使用回车(CR)和换行(LF)两个字符来结束一行,回车+换行(CR+LF),即“\r\n”; (B)Unix和mac下:只使用换行(LF)一个字符来结束一行,即“\n”; (最早Mac每行结尾是回车CR 即'\r',后mac os x 也投奔了 unix) (2)Git下处理“换行”(line ending) core.autocrlf是git中负责处理line ending的变量,可以设置3个值:true,false,input。 (A)设置为true【config --global core.autocrlf true】 当设置成true时,这意味着你在任何时候添加(add)文件到git仓库时,git都会视为它是一个文本文件(text file)。 它将把crlf变成LF。 (B)设置为false【config --global core.autocrlf false】 当设置成false时,line endings将不做转换操作。文本文件保持原来的样子。 (C)设置为input时,添加文件git仓库时,git把crlf编程lf。当有人Check代码时还是lf方式。因此在window操作系统下,不要使用这个设置。 4.此问题的负面影响 格式化与多余的空白字符,特别是在跨平台情况下,有时候是一个令人发指的问题。由于编辑器的不同或者文件行尾的换行符在 Windows 下被替换了,一些细微的空格变化会不经意地混入提交,造成麻烦。虽然这是小问题,但会极大地扰乱跨平台协作。 假如你正在Windows上写程序;又或者你正在和其他人合作,他们在Windows上编程,而你却在其他系统上,在这些情况下,你可能会遇到行尾结束符问题。此问题的全部负面影响如下: (1)一个直接后果是,Unix/Mac系统下的一个“多行文本”文件在Windows里打开的话,“多行文本”会变成“一行”。(原因:Unix/Mac换行只用了换行符‘\n’,而Windows的换行要求是回车换行符’\r\n’,因此Unix/Mac中的“多行文本”的换行不符合Windows的规则,所以Windows对这些不符合换行规则的“多行文本”全部按照“没有换行”处理,所以导致“多行文本”会变成“一行”) (2)而Windows里的文件在Unix/Mac下打开的话,在每行的结尾可能会多出一个^M符号。 (3)Linux保存的文件在windows上用记事本看的话会出现黑点。 5.解决此问题的方案 (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个功能来避免我们出错: (A)在“把 modified修改过的文件git add到暂存区stage”时,Git自动把LF转换成CRLF,并给出那条警告”LF will be replaced by CRLF” (B)在“把modified修改过的文件由暂存区(stage) 提交(commit)到版本库/仓库(repository)”时,Git自动把CRLF转换成LF (C)在“用 检出/git checkout切换到指定分支 或 git clone克隆远程版本库”来加载代码时,Git自动把LF转换成CRLF 提到的那句警告:“IF will be replaced by CRLF in <file-name>” 这句警告的下面其实还有一句很重要的话:The file will have its original line endings in your working directory. (翻译:"在工作区里,这个文件会保留它原本的换行符") (2)如果我们是Linux 或 Mac平台,我们不需要5(1)(C)的功能“在检出或克隆远程版本库时,Git自动把LF转换成CRLF”。然而当一个CRLF作为行结束符的文件在我们的Linux 或 Mac平台不小心被引入时,你肯定想让 Git 修正。 所以,你可以通过config --global core.autocrlf input命令把 core.autocrlf 设置成 input 来告诉 Git 在提交(commit)时把CRLF转换成LF,检出(git checkout)时不转换 (1)+(2):这样在 Windows 上的检出(checkout)文件中会保留CRLF,而在 Mac 和 Linux 上,以及版本库中会保留LF,从而保证我们项目团队正常跨系统git操作代码 本文参考来源: [1] https://www.jianshu.com/p/450cd21b36a4 [2] https://blog.csdn.net/tfstone/article/details/79822747 [3] https://blog.csdn.net/qq_37859539/article/details/79870835