Git 提示 “warning: LF will be replaced by CRLF“的思考

souching

已于 2023-03-04 12:13:03 修改

阅读量3.5k

点赞数 2

分类专栏：其他文章标签： git github windows

于 2023-03-04 12:09:27 首次发布

本文链接：https://blog.csdn.net/souching/article/details/129331271

版权

其他专栏收录该内容

7 篇文章 0 订阅

订阅专栏

在windows平台进行 git add 时, 控制台有时会打印警告 warning: in the working copy of ‘XXX.sh’, LF will be replaced by CRLF the next time Git touches it.
查看了一些资料, 大概弄清了 core.autocrlf 配置选项的作用:

git config --global core.autocrlf true
适用于Windows系统, 且一般为Windows默认设置, 会在提交时对换行符进行CRLF->LF的转换, 检出时又会进行LF->CRLF的转换.

我目前在windows平台工作, core.autocrlf 配置为 true, 我明白了是因为要进行转换所以会进行告警, 但我还是有一些疑惑:
1. 在上面的告警语句中, the next time git touches it 指代什么? working copy 又指什么?
2. 另外, 我本地unix格式的文件(我一般是通过tortoisegit 进行commit, push和pull的), 经过多次修改提交后格式却没有变化; 但是当我clone一个库后, 确实该文件会由unix格式变成了windows格式, 为什么?

我又看到一个资料, 似乎暂时能解释心中的疑惑了:

问题描述:
windows平台下使用git add, git deploy 文件时经常出现"warning: LF will be replaced by CRLF"的提示:
jedlee@JedsLaptop MINGW64 ~/Desktop/HtmlProject (master)
$ git add .idea
warning: LF will be replaced by CRLF in .idea/workspace.xml.
The file will have its original line endings in your working directory

解决此问题的方案:
(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 //采出clone时, 从远程得到文件果然全部变成了windows格式
提到的那句警告: “IF will be replaced by CRLF in xxx”, 这句警告的下面其实还有一句很重要的话: 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操作代码;

自己理解的答案:

针对第一个疑惑: 当add时, 会把"把modified的文件git add到暂存区stage", 虽然我不清楚stage是什么, 但我想它应该是在本地, 它里面的内容会以CRLF结尾, 故会进行LF->CRLF的转换; 而"把modified的文件由暂存区(stage)提交(commit)到版本库/仓库(repository)"时, Git自动把CRLF转换成LF; 这个仓库的内容push后应该本地和远方是一致的吧?
warning: in the working copy of ‘XXX.sh’, LF will be replaced by CRLF the next time Git touches it 应该就是在转换之前给出的, the next time git touches it 应该指的是接下来的转换; the working copy of 'XXX.sh’应该是指stage区内的文件;
或者该警告是说: 当git下次检出时, 该文档的LF会被CRLF取代?
无论如何, 当 autocrlf 为 true 时, 对于想在本地保存unix格式的文件来说, 应该都不是安全的;
针对第二个疑惑, 可能因为我的项目都是自己使用的缘故, 我一般是通过 tortoisegit 进行 git pull 操作, 似乎这种操作不会更动原文件吧; 而当我进行 git clone 时, 则会从repository中恢复文档, 故我原来的unix格式文件会变成windows格式, 这也是一个隐患所在;

总结:
对于我上面第二个引用的描述, 他给出的解决方案其实适合项目中涉及不同平台的合作开发, 故win平台用(1)选项, 而linux平台用(2)选项;
而对于我一个人开发的项目(多人开发但只要不跨平台应该也可以), 主要还是在win平台编辑, 但还需要备份linux平台使用的文件, 但会在几个电脑之间进行同步;
那么对于我来说, 最好用的选项应该是: autocrlf false (在提交、检出时不会对CRLF/LF换行符进行转换)
它的好处是: 少了换行符的转换, 可以加快操作速度; 同时也保证了备份unix格式文件的完整性;

引文链接:
https://blog.csdn.net/Babylonxun/article/details/126598477
https://blog.csdn.net/wq6ylg08/article/details/88761581