确保在.gitignore文件中添加了不必要的文件或文件夹。

如。 node_modules

如果仍然面对，则运行此命令

git配置——全局核心。autocrlf假的' '

是的，警告是反的。

事实上，它一开始就不应该是一个警告。因为所有这些警告都在说(但不幸的是倒着说)，你文件中带有Windows行结束符的CRLF字符将在提交时被LF字符替换。这意味着它被标准化为*nix和MacOS使用的相同的行结束符。

没有什么奇怪的事情发生，这正是你通常想要的行为。

当前形式的警告是以下两件事之一:

一个不幸的漏洞加上一个过于谨慎的警告信息， 或 一个非常聪明的情节，让你真正思考这个问题……

;)

警告:LF将被CRLF取代。

根据您使用的编辑器的不同，带有LF的文本文件不一定要用CRLF保存:最近的编辑器可以保留eol样式。但是git的配置设置坚持要更改这些…

只要确保(正如我在这里建议的):

git config --global core.autocrlf false

这样，您就避免了任何自动转换，并且仍然可以通过.gitattributes文件和核心指定它们。eol指令。

---

windows git“LF将被CRLF取代”

注意:警告信息已在Git 2.37 (Q3 2022)中更改

这个警告尾巴是向后的吗?

不:你在Windows上，git配置帮助页面确实提到了

如果您希望在工作目录中有CRLF行结束符，即使存储库没有规范化的行结束符，也可以使用此设置。

正如“git用CRLF替换LF”中所描述的，它应该只发生在签出(而不是提交)时，core. selflf =true。

       repo
    /        \ 
crlf->lf    lf->crlf 
 /              \    

正如小鹏的回答中提到的，这个警告是:

警告:(如果你检出/或克隆到另一个文件夹与你当前的核心。自自配置，)LF将被CRLF取代 该文件将在您的(当前)工作目录中有其原始的行结束符。

如git-for-windows/git issue 1242中所述:

我仍然觉得这条消息令人困惑，这条消息可以扩展到包括一个更好的解释，例如:“LF将被文件中的CRLF取代。Json后删除文件并再次签出”。

注意:Git 2.19(2018年9月)，当使用核心。专制者，虚假的“LF” “CRLF”的警告现在被压制。

---

正如quaylar正确地评论的那样，如果在commit上有一个转换，它只是到LF。

特定的警告“LF将被CRLF取代”来自convert.c#check_safe_crlf():

if (checksafe == SAFE_CRLF_WARN)
  warning("LF will be replaced by CRLF in %s.
           The file will have its original line endings 
           in your working directory.", path);
else /* i.e. SAFE_CRLF_FAIL */
  die("LF would be replaced by CRLF in %s", path);

它由convert.c#crlf_to_git()调用，本身由convert.c#convert_to_git()调用，本身由convert.c#renormalize_buffer()调用。

最后一个renormalize_buffer()只能由merge-recursive.c#blob_unchanged()调用。

所以我怀疑只有当提交是merge过程的一部分时，这种转换才会发生在git提交上。

---

注意:在Git 2.17(2018年第二季度)中，代码清理增加了一些解释。

参见Torsten提交8462ff4(2018年1月13日)Bögershausen (tboegi)。 (由Junio C Hamano—gitster—在commit 9bc89b1中合并，2018年2月13日)

Convert_to_git (): safe_crlf/checksafe变成int conv_flags

在调用convert_to_git()时，checksafe参数定义了what 如果EOL转换(CRLF—> LF—> CRLF)没有发生，应该发生什么 往返干净。 此外，它还定义了行结束符是否应该重新正规化(CRLF—> LF)或保持原样。

Checksafe是一个safe_crlf枚举，包含以下值:

SAFE_CRLF_FALSE:       do nothing in case of EOL roundtrip errors
SAFE_CRLF_FAIL:        die in case of EOL roundtrip errors
SAFE_CRLF_WARN:        print a warning in case of EOL roundtrip errors
SAFE_CRLF_RENORMALIZE: change CRLF to LF
SAFE_CRLF_KEEP_CRLF:   keep all line endings as they are

---

注意在8462ff4中引入的回归("convert_to_git(): “safe_crlf/checksafe变成int conv_flags”，2018-01-13,Git 2.17.0)返回到Git 2.17周期导致selflf重写产生警告消息 尽管设置了safecrlf=false。

参见Anthony Sottile (asottile)提交的commit 6cb0912(2018年6月04日)。 (由Junio C Hamano—gitster—在commit 8063ff9中合并，2018年6月28日)

我遇到过类似的问题，在windows上使用vscode(v1.57)尝试了其他答案中定义的解决方案，但没有工作。

所以对我来说，以下步骤是有效的:

在根文件夹中有一个名为.editorconfig的文件 打开该文件，将end_of_line = lf修改为end_of_line = CRLF 运行git rm——缓存，警告消失!!

在我设定核心之后。我得到了“LF将被CRLF取代”(注意不是“CRLF将被LF取代”)当我在git添加(或者可能是它在git提交?)编辑文件在窗口上的存储库(使用LF)，在我设置core. selflf =true之前签出。

我用core做了一个新的结账。selflf =true，现在我没有得到这些消息。

所有这些都假设core. selflf =true

原始错误:

警告:LF将被CRLF取代 该文件在您的工作目录中有其原始的行结束符。

错误应该是什么:

警告:在你的工作目录中，LF将被CRLF取代 文件将在git存储库中有其原始的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.

基本上，以前是LF的本地文件现在在本地具有CRLF