在 Windows 机器上，我使用 git add 添加了一些文件。我收到警告说：
LF 将被 CRLF 取代
这种转换的后果是什么？
这些消息是由于 Windows 上的 core.autocrlf 的默认值不正确。
autocrlf 的概念是透明地处理行尾转换。确实如此！
坏消息：该值需要手动配置。
好消息：每个 Git 安装只能执行一次（也可以按项目设置）。
autocrlf 的工作原理：
core.autocrlf=true: core.autocrlf=input: core.autocrlf=false:
repository repository repository
^ V ^ V ^ V
/ \ / \ / \
crlf->lf lf->crlf crlf->lf \ / \
/ \ / \ / \
这里 crlf = win 样式的行尾标记，lf = unix 样式（自 Mac OS X 起也用于 Mac）。
（以上三个选项中的任何一个都不影响 pre-osx cr。）
此警告何时出现（在 Windows 下）？
– autocrlf = true 如果您的一个文件中有 unix 风格的 lf（= 很少），
– autocrlf = input 如果您的一个文件中有 win 风格 crlf（= 几乎总是），
– autocrlf = false – 绝不！
这个警告是什么意思？
警告“LF 将被 CRLF 替换”表示您（具有 autocrlf=true）将在提交签出周期后丢失您的 unix 样式的 LF（它将被 windows-样式 CRLF）。 Git 不希望你在 Windows 下使用 unix 风格的 LF。
警告“CRLF 将被 LF 替换”表示您（具有 autocrlf=input）将在提交签出周期后丢失 Windows 样式的 CRLF（它将被 unix 替换风格的LF）。不要在 Windows 下使用 input。
展示 autocrlf 工作原理的另一种方式
1) true: x -> LF -> CRLF
2) input: x -> LF -> LF
3) false: x -> x -> x
其中 x 是 CRLF（windows 风格）或 LF（unix 风格），箭头代表
file to commit -> repository -> checked out file
怎么修
core.autocrlf 的默认值在 Git 安装期间选择并存储在系统范围的 gitconfig 中（Windows 上为 %ProgramFiles(x86)%\git\etc\gitconfig，Linux 上为 /etc/gitconfig）。还有（按以下顺序级联）：
– 位于 ~/.gitconfig 的“全局”（每个用户）gitconfig，还有另一个
– $XDG_CONFIG_HOME/git/config 或 $HOME/.config/git/config 和
的“全局”（每个用户）gitconfig – 工作目录中 .git/config 处的“本地”（每个 repo）gitconfig。
因此，在工作目录中写入 git config core.autocrlf 以检查当前使用的值和
– git config --system core.autocrlf false # 按系统解决方案
– git config --global core.autocrlf false # 每用户解决方案
– git config --local core.autocrlf false # 每个项目的解决方案
警告
– git config 设置可以被 gitattributes 设置覆盖。
– crlf -> lf 转换仅在添加新文件时发生，crlf 文件已经回购中存在的不受影响。
道德（对于 Windows）：
- 如果您也打算在 Unix 下使用这个项目（并且不愿意将您的编辑器/IDE 配置为使用 unix 行尾），请使用 core.autocrlf = true，
; - 如果您打算仅在 Windows 下使用此项目（或者您已将编辑器/IDE 配置为使用 unix 行尾），请使用 core.autocrlf = false，
;- 从不使用 core.autocrlf = input 除非你有充分的理由（例如如果你在 Windows 下使用 unix 实用程序或者遇到 makefile 问题),
PS 安装 Git for Windows 时要选择什么？
如果您不打算在 Unix 下使用任何项目，请不要同意默认的第一个选项。选择第三个（按原样结帐，按原样提交）。您不会看到此消息。曾经。
PPS：我个人的偏好是将 editor/IDE 配置为使用 unix 风格的结尾，并将 core.autocrlf 设置为 false。
Git 有三种处理行尾的模式：
# This command will print "true" or "false" or "input"
git config core.autocrlf
您可以通过在上述命令行中添加附加参数 true 或 false 来设置要使用的模式。
如果 core.autocrlf 设置为 true，这意味着每当您将文件添加到 Git 存储库中 Git 认为是文本文件时，它会将所有 CRLF 行结尾仅转换为 LF，然后再将其存储到提交中。每当您 git checkout 某些东西时，所有文本文件都会自动将其 LF 行结尾转换为 CRLF 结尾。这允许跨使用不同行尾样式的平台开发项目，而不会产生非常嘈杂的提交，因为每个编辑器都会更改行尾样式，因为行尾样式始终是 LF。
这种方便转换的副作用，这就是您所看到的警告，如果您最初创作的文本文件以 LF 结尾而不是 CRLF 结尾，它将像往常一样与 LF 一起存储，但在签出时稍后它将有 CRLF 结尾。对于普通的文本文件，这通常很好。在这种情况下，警告是“供您参考”，但如果 Git 错误地将二进制文件评估为文本文件，这是一个重要的警告，因为 Git 会破坏您的二进制文件。
如果 core.autocrlf 设置为 false，则不会执行任何行尾转换，因此文本文件按原样签入。这通常可以正常工作，只要您的所有开发人员都在 Linux 上或全部在 Windows 上。但根据我的经验，我仍然倾向于得到带有混合行尾的文本文件，最终导致问题。
作为 Windows 开发人员，我个人的偏好是将设置保持打开状态。
请参阅 git-config 了解包含“输入”值的更新信息。
core.eol 设置的比较来扩充这个写得很好的答案，也许与 .gitattributes 配置相一致。我一直试图通过实验找出差异和重叠，这非常令人困惑。
如果您已签出代码，则文件已编入索引。更改 Git 设置后，例如运行：
git config --global core.autocrlf input
您应该刷新索引
git rm --cached -r .
并用重写 Git 索引
git reset --hard
注意：这将删除您的本地更改。考虑在执行此操作之前将它们存放起来。
来源：Configuring Git to Handle Line Endings
git rm --cached -r . 是什么意思？为什么 git reset --hard 还不够？
git rm --cached -r . 如果您在更改 core.autocrlf 设置后执行 git reset --hard，它将不会重新转换行尾。您需要清理 git 索引。
git config core.autocrlf false
autcrlf 设置为 false 只是将问题推给项目的每个用户。
git config --global core.autocrlf false。
unix2dos 和 dos2unix 在带有 Git Bash 的 Windows 上可用。您可以使用以下命令执行 UNIX (LF) → DOS (CRLF) 转换。因此，您不会收到警告。
unix2dos filename
或者
dos2unix -D filename
但是，不要在任何现有的 CRLF 文件上运行此命令，因为这样您将每隔两行得到空换行符。
dos2unix -D filename 不适用于所有操作系统。请检查 this link 的兼容性。
如果由于某种原因您需要强制执行该命令，请使用 --force。如果显示无效，则使用 -f。
dos2unix -D 会将 windows 行尾转换为 linux 行尾。这和 DOS(CRLF) 不一样吗？ UNIX(LF) 转换。但是 dos2unix -h 声明 -D 将执行 UNIX(LF) -> DOS（CRLF）转换。 dos2unix 更多信息：gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unix
在谈论这个话题时通常会提到 GitHub article on line endings。
我个人对使用经常推荐的 core.autocrlf 配置设置的体验非常复杂。
我正在使用带有 Cygwin 的 Windows，在不同时间处理 Windows 和 Unix 项目。甚至我的 Windows 项目有时也会使用需要 Unix (LF) 行结尾的 Bash shell 脚本。
使用 GitHub 为 Windows 推荐的 core.autocrlf 设置，如果我签出一个 Unix 项目（它在 Cygwin 上完美运行 - 或者我正在为我在我的 Linux 服务器上使用的项目做出贡献），文本文件将被签出Windows (CRLF) 行尾，产生问题。
基本上，对于像我这样的混合环境，将全局 core.autocrlf 设置为任何选项在某些情况下都无法正常工作。此选项可能在本地（存储库）Git 配置中设置，但即使这样对于包含 Windows 和 Unix 相关内容的项目也不够好（例如，我有一个带有一些 Bash 实用程序脚本的 Windows 项目） .
我发现的最佳选择是创建每个存储库的 .gitattributes 文件。 GitHub article 提到了它。
那篇文章的例子：
# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto
# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text
# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf
# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary
在我的项目的一个存储库中：
* text=auto
*.txt text eol=lf
*.xml text eol=lf
*.json text eol=lf
*.properties text eol=lf
*.conf text eol=lf
*.awk text eol=lf
*.sed text eol=lf
*.sh text eol=lf
*.png binary
*.jpg binary
*.p12 binary
设置的东西要多一些，但每个项目只做一次，任何操作系统上的任何贡献者在处理这个项目时都应该不会遇到行尾问题。
text=false eol=false 的工作方式与 binary 有点相似。听起来对吗？指示“我知道这些是文本文件，但我不希望它们被规范化”可能很有用
我认为 Basiloungas's answer 很接近，但已过时（至少在 Mac 上）。
打开 ~/.gitconfig 文件并将 safecrlf 设置为 false：
[core]
autocrlf = input
safecrlf = false
这 * 将使它显然忽略行尾字符（无论如何它对我有用）。
safecrlf（带有“f”）
在 Vim 中，打开文件（例如：:e YOURFILEENTER），然后
:set noendofline binary
:wq
vim 编辑将使所有行结尾保持不变。
我也有这个问题。
SVN 不进行任何行尾转换，因此文件以完整的 CRLF 行尾提交。如果您随后使用 git-svn 将项目放入 git 中，那么 CRLF 结尾会一直存在到 git 存储库中，这不是 git 期望找到的状态 - 默认情况下只有 unix/linux (LF) 行结尾入住。
然后，当您在 Windows 上签出文件时，autocrlf 转换会使文件保持原样（因为它们已经具有当前平台的正确结尾），但是决定与签入文件是否存在差异的过程会执行反向转换在比较之前，将它认为是签出文件中的 LF 与存储库中的意外 CRLF 进行比较。
据我所知，您的选择是：
在不使用 git-svn 的情况下将代码重新导入新的 git 存储库，这将意味着在初始 git commit 中转换行尾 --all 将 autocrlf 设置为 false，并忽略行尾不是 git 首选样式的事实在 autocrlf 关闭的情况下检查您的文件，修复所有行结尾，重新检查所有内容，然后再次打开它。重写存储库的历史记录，以便原始提交不再包含 git 不期望的 CRLF。 （关于历史重写的常见警告适用）
脚注：如果您选择选项 #2，那么我的经验是某些辅助工具（rebase、patch 等）无法处理 CRLF 文件，您迟早会遇到混合了 CRLF 和 LF 的文件（不一致的行结局）。我知道没有办法两全其美。
rebase 对 CRLF 没有问题。我知道的唯一问题是标准 git 合并工具将插入其冲突标记（“<<<<<<”、“>>>>>>”等。 ) 仅使用 LF，因此具有冲突标记的文件将具有混合行结尾。但是，一旦您删除标记，一切都很好。
从 ~/.gitattributes 文件中删除以下内容，
* text=auto
将阻止 Git 首先检查行尾。
false，如果不删除这个，将 autocrlf 设置为 false 将无济于事，所以这个对我有帮助（但它本身还不够）。
.gitattributes 中的 text= 设置的答案（如果存在，它将成为一个阻止程序）。所以其他答案不完整。我疯了想弄清楚为什么我的文件继续显示为“已修改”，无论我更改了多少次我的 autocrlf 和 safecrlf 设置和签出&清除了 git 缓存 &硬重置。
Windows 中的大多数工具也接受文本文件中的简单 LF。例如，您可以使用以下示例内容（部分）在名为“.editorconfig”的文件中控制 Visual Studio 的行为：
indent_style = space
indent_size = 2
end_of_line = lf <<====
charset = utf-8
只有最初的 Windows Notepad 不能与 LF 一起使用，但有一些更合适的简单编辑器工具可用！
因此，您也应该在 Windows 的文本文件中使用 LF。这是我的信息，强烈推荐！没有任何理由在 Windows 中使用 CRLF！
（同样的讨论是在 C/++ 中的包含路径中使用 \。它是牛粪。使用带有斜线的 #include <pathTo/myheader.h>！，它是 C/++ 标准和所有 Microsoft编译器支持它）。
因此，Git 的正确设置是：
git config core.autocrlf false
我的信息：忘记像 dos2unix 和 unix2dos 这样的旧思维程序。在您的团队中澄清 LF 适合在 Windows 下使用。
How to make Git ignore different line endings
http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/（不工作）
您可以完全禁用 CRLF 行为，或者通过更改 .gitattributes 文件中的条目来禁用每个文件类型。在我的例子中，我这样写： -crlf 这告诉 Git 忽略所有文件的行尾。并且不会更改工作目录中的文件。即使您将 core.autocrlf 设置为 true、false 或 input。
echo "* -crlf" > .gitattributes
在单独的提交上执行此操作，否则 Git 可能仍会在您进行单个更改时看到整个文件已修改（取决于您是否更改了 autocrlf 选项）。
这个真的很管用。 Git 将尊重混合行结尾项目中的行结尾，并且不会警告您。
*.sh -crlf...
git rm --cached -r . 和 git reset --hard 它适用于项目中的每个人。
我对 Windows 上的 Git 不太了解，但是...
在我看来，Git 正在转换返回格式以匹配运行平台（Windows）的格式。 CRLF 是 Windows 上的默认返回格式，而 LF 是大多数其他操作系统的默认返回格式。
很有可能，当代码移动到另一个系统时，返回格式将被正确调整。我还认为 Git 足够聪明，可以保持二进制文件完整，而不是尝试将 LF 转换为 CRLF，例如 JPEG 文件。
总之，您可能不需要对这种转换过于担心。但是，如果您将项目归档为 tarball，其他编码人员可能会喜欢使用 LF 行终止符而不是 CRLF。根据您的关心程度（并且取决于您不使用 Notepad），如果可以的话，您可能希望将 Git 设置为使用 LF 返回 :)
附：CR是ASCII码13，LF是ASCII码10。因此，CRLF是两个字节，而LF是一个字节。
它应该是：
警告：（如果您将其签出/或克隆到另一个文件夹且当前 core.autocrlf 为真，）LF 将被替换为 CRLF 该文件将在您的（当前）工作目录中具有其原始行结尾。
这张图片应该解释它的含义。
https://i.stack.imgur.com/ZXee5.jpg
确保您已安装最新版本的 Git
在使用 Git（版本 2.7.1）时，我按照上一个答案 git config core.autocrlf false 中的方式进行了操作，但它不起作用。
然后它现在可以在升级 git（从 2.7.1 到 2.20.1）时工作。
在记事本++中打开文件。转到菜单编辑 → EOL 转换。单击 Windows 格式。保存文件。
git config --global core.autocrlf false 来防止 Git 在提交时将行尾设置为 Unix。跟进 git config core.autocrlf 以检查它是否确实设置为 false。
OP 的问题与 Windows 相关，如果不转到目录，甚至在 Notepad++ 中运行文件，我就无法使用其他人，因为管理员没有工作......
所以不得不走这条路：
cd "C:\Program Files (x86)\Git\etc"
git config --global core.autocrlf false
在两种不同的操作系统（Linux 和 Windows）中使用“代码”时，CRLF 可能会导致一些问题。
我的 Python 脚本是在 Linux Docker 容器中编写的，然后使用 Windows 的 Git Bash 推送。它给了我LF将被CRLF取代的警告。我没有多想，但后来当我开始脚本时，它说：
/usr/bin/env: 'python\r': 没有这样的文件或目录
现在，这是一个对您产生影响的 \r。 Windows 使用“CR” - 回车 - 在 '\n' 顶部作为换行符 - \n\r。这是你可能需要考虑的事情。
许多文本编辑器允许您更改为 LF。请参阅下面的 Atom 说明。它简单明了。
点击右下角的CRLF：
https://i.stack.imgur.com/4qwaQm.png
在顶部的下拉列表中选择 LF：
https://i.stack.imgur.com/l9b9Ll.png
我只是有同样的错误。在 Windows 10 上安装 NVM NVM 后发生。
在所有级别设置 autoclrf 均无效。
在 CMD 中，我使用了：“git ls-files --eol”
i/lf w/crlf attr/ src/components/quotes/ExQuoteForm.js
i/lf w/lf attr/ src/components/quotes/HighlightedQuote.js
结论：
我制作的文件有不同的结局。
要更改文件并重置，请执行
git config core.autocrlf false
git rm --cached -r .
git reset --hard
虽然：
在某些项目中，我需要删除存储库并重新启动它。
对于一般概念，其他答案非常棒。我遇到了一个问题，在更新警告后仍然发生在先前设置中已提交的现有存储库上。
添加 --renormalize 有助于，例如，
git add --renormalize .
" 对所有跟踪的文件重新应用“清理”过程，以强制将它们再次添加到索引中。这在更改 core.autocrlf 配置或文本属性后很有用，以更正添加了错误 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（回车和换行）
代表 CARRIAGE RETURN 和 LINE FEED
用 /n/r 表示
创建一个新行并将光标放在该新行的开头。
ASCII 码是 10 表示 LF，13 表示 CR。
主要用于 Windows 操作系统。
Git 默认使用 LF。所以当我们在 Windows 上使用 Git 时，它会抛出类似“CRLF 将被 LF 替换”的警告，并自动将所有 CRLF 转换为 LF，从而使代码变得兼容。
注意：别担心……不要将此视为警告，而应将其视为通知消息。
我遇到了同样的问题，并且做 git add . && git reset 正确地恢复了所有行尾。
关注公众号
不定期副业成功案例分享
core.autocrlf设置为输入？根据我从您的回答中收集到的信息，将其设置为 input 可确保存储库和工作目录始终具有 unix 样式的行结尾。为什么您从不希望在 Windows 中使用它？input将转换我的行尾，如果我 不小心 在某个地方有一个 CRLF（也许你曾经在记事本中快速编辑而不是你配置良好的 IDE！），而不影响所有有意的 LF。使用false的缺点是，如果我有一个意外的 CRLF，我可能会不小心将它提交给 repo。input会阻止这种情况！所以input>false，不是吗？