在一台Windows机器上,我使用git add添加了一些文件。 我收到警告说:
LF将被CRLF取代
这种转变的后果是什么?
在一台Windows机器上,我使用git add添加了一些文件。 我收到警告说:
LF将被CRLF取代
这种转变的后果是什么?
当前回答
CR和LF是一组特殊的字符,用于帮助格式化代码。
CR (/r)将光标放在一行的开头,但不创建新的行。这就是macOS的工作原理。
LF (/n)创建了一个新行,但它不会将光标放在该行的开头。光标停留在最后一行的末尾。这就是Unix和Linux的工作原理。
CRLF (/r/f)创建新行,并将光标放在新行开头。这就是我们在Windows操作系统中看到的情况。
总结:
Lf(换行)
代表换行 用/n表示 在代码中创建新行 ASCII码是10。 用于Unix和其他基于它的操作系统。
Cr(车厢返程)
代表回车 用/r表示 将光标放在行首。 ASCII码是13。 macOS及其前身使用。
CRLF(回车换行)
代表回车和换行 用/n/r表示 创建新行,并将光标放在新行开头。 LF的ASCII码是10,CR的ASCII码是13。 主要用于Windows操作系统。
Git默认使用LF。因此,当我们在Windows上使用Git时,它会抛出一个像“CRLF将被LF取代”这样的警告,并自动将所有CRLF转换为LF,因此代码变得兼容。
NB:别担心……不要把这看作是警告,而应该把它看作是通知消息。
其他回答
在notepad++中打开文件。 进入菜单编辑→EOL转换。 单击Windows格式。 保存文件。
其他答案对于一般概念来说是非常棒的。我遇到了一个问题,在更新警告后,仍然发生在现有的存储库,在以前的设置中提交。
加上——renoralize有帮助,例如:
Git添加——重新规范化。
从文档中可以看到:
将“清洁”进程新应用于所有跟踪文件,以强制执行 将它们再次添加到索引中。这在更改后很有用 核心。自专制配置或文本属性,以纠正 添加了错误的CRLF/LF行结束符的文件。这个选项意味着-u。”
CR和LF是一组特殊的字符,用于帮助格式化代码。
CR (/r)将光标放在一行的开头,但不创建新的行。这就是macOS的工作原理。
LF (/n)创建了一个新行,但它不会将光标放在该行的开头。光标停留在最后一行的末尾。这就是Unix和Linux的工作原理。
CRLF (/r/f)创建新行,并将光标放在新行开头。这就是我们在Windows操作系统中看到的情况。
总结:
Lf(换行)
代表换行 用/n表示 在代码中创建新行 ASCII码是10。 用于Unix和其他基于它的操作系统。
Cr(车厢返程)
代表回车 用/r表示 将光标放在行首。 ASCII码是13。 macOS及其前身使用。
CRLF(回车换行)
代表回车和换行 用/n/r表示 创建新行,并将光标放在新行开头。 LF的ASCII码是10,CR的ASCII码是13。 主要用于Windows操作系统。
Git默认使用LF。因此,当我们在Windows上使用Git时,它会抛出一个像“CRLF将被LF取代”这样的警告,并自动将所有CRLF转换为LF,因此代码变得兼容。
NB:别担心……不要把这看作是警告,而应该把它看作是通知消息。
Git有三种模式来处理行结束符:
# This command will print "true" or "false" or "input"
git config core.autocrlf
您可以通过向上面的命令行添加一个额外的true或false参数来设置要使用的模式。
If core.autocrlf is set to true, that means that any time you add a file to the Git repository 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.
如果核心。将selflf设置为false,则不会执行任何行结束转换,因此文本文件将按原样检入。这通常是可行的,只要你所有的开发人员都在Linux或Windows上。但根据我的经验,我仍然倾向于得到带有混合行结束符的文本文件,最终导致问题。
作为一名Windows开发人员,我个人倾向于让这个设置打开。
请参阅git-config以获得包含“input”值的更新信息。
许多文本编辑器允许您更改为LF。请参阅下面的Atom指令。它简单明了。
点击右下角的CRLF:
在顶部的下拉菜单中选择LF: