我认为Basiloungas的答案很接近，但已经过时了(至少在Mac上)。

打开~/。并将safecrlf设置为false:

[core]
       autocrlf = input
       safecrlf = false

*显然会使它忽略行char的结尾(它对我来说是有效的)。

我不太了解Windows上的Git，但是……

在我看来，Git正在转换返回格式以匹配正在运行的平台(Windows)。CRLF是Windows上的默认返回格式，而LF是大多数其他操作系统的默认返回格式。

当代码被移动到另一个系统时，返回格式可能会得到适当的调整。我还认为Git足够聪明，可以保持二进制文件的完整性，而不是试图在JPEG文件中将lf转换为crlf。

总而言之，您可能不需要为这种转换担心太多。但是，如果您将项目归档为tarball，其他编码员可能会喜欢使用LF行终止符而不是CRLF。取决于你有多关心(取决于你不使用记事本)，你可能想要设置Git使用LF返回，如果你可以的话:)

附录:CR为ASCII码13,LF为ASCII码10。因此，CRLF是两个字节，而LF是一个字节。

其他答案对于一般概念来说是非常棒的。我遇到了一个问题，在更新警告后，仍然发生在现有的存储库，在以前的设置中提交。

加上——renoralize有帮助，例如:

Git添加——重新规范化。

从文档中可以看到:

将“清洁”进程新应用于所有跟踪文件，以强制执行 将它们再次添加到索引中。这在更改后很有用 核心。自专制配置或文本属性，以纠正 添加了错误的CRLF/LF行结束符的文件。这个选项意味着-u。”

unix2dos和dos2unix都可以在Windows Git Bash上使用。可以使用以下命令进行UNIX (LF)→DOS (CRLF)转换。因此，您将不会得到警告。

unix2dos filename

or

dos2unix -D filename

但是，不要在任何现有的CRLF文件上运行这个命令，因为这样每隔两行就会得到空换行符。

dos2unix -D文件名不适用于所有操作系统。请检查此链接的兼容性。

如果出于某种原因你需要强制执行命令，那么使用——force。如果它表示无效，则使用-f。

git config core.autocrlf false

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:别担心……不要把这看作是警告，而应该把它看作是通知消息。