Git 用 CRLF 替换 LF

Question

在 Windows 计算机上，我使用 git add 添加了一些文件。 我收到警告说：

LF 将被 CRLF 替换

这种转换会产生什么后果？

Answer 1

OP的问题与Windows相关，我无法在不进入目录甚至运行文件的情况下使用其他问题 Notepad++ 作为管理员不起作用...

所以必须走这条路：

cd "C:\Program Files (x86)\Git\etc"
git config --global core.autocrlf false

Answer 2

许多文本编辑器允许您更改为LF。请参阅下面的 Atom 说明。它简单而明确。

---

点击右下角的CRLF：

在顶部下拉列表中选择 LF：

Answer 3

在 GNU/Linux shell 提示符中， dos2unix 和 unix2dos 命令允许您轻松转换/格式化来自 MS Windows 的文件。

Answer 4

CR 和 LF 是一组特殊的字符，有助于格式化我们的代码。

CR (\r) 将光标置于行首，但不创建新行。这就是 macOS 旧版本（目前不适用）的工作原理。

LF (\n) 创建一个新行，但不会将光标置于该行的开头。光标停留在最后一行的末尾。这就是 Unix（包括 macOS）和 Linux 的工作方式。

CRLF (\r\n) 创建一个新行并将光标置于新行的开头。这就是我们在 Windows 操作系统中看到的方式。

总结一下：

1. LF (LINE FEED)

• 代表换行
• ，用 \n 表示
• 在代码中创建一个新行。
• ASCII 代码为 10。
• 由 Unix 和其他类似或基于它的操作系统使用，例如 Linux 和现代 macOS。

2. CR (CARRIAGE RETURN)

• 代表回车符
• ，用 \r 表示，
• 将光标置于行首。
• ASCII 代码为 13。
• 在 Mac OS X 之前的 macOS 旧版本中使用。

3. CRLF (CARRIAGE RETURN AND LINE FEED)

• 代表回车和换行，
• 用 \r\n 表示
• 创建一个新行并将光标放在行首。那条新线。
• LF 的 ASCII 代码为 10，CR 的 ASCII 代码为 13。
• 主要用于Windows操作系统。

Git 默认使用 LF。因此，当我们在 Windows 上使用 Git 时，它会抛出类似“CRLF 将被 LF 替换”的警告，并自动将所有 CRLF 转换为 LF，以便代码变得兼容。

注意：别担心……不要将其视为警告，而应将其视为通知消息。

Answer 5

您可以通过创建一个名为 .gitattributes 的文件并将其放入其中来轻松解决：

*.sh text eol=lf

其中“sh”是每个文件的扩展名，需要 LF 而不是 CRLF。我想你的情况是这样吗

Answer 6

在 Windows 上，我收到此警告是因为我的文件名太长。
将我的文件重命名为更短的文件（并重新启动我的编辑器 VS Code）后，错误消失了。

Answer 7

要显示配置您的设置的 gitconfig 文件，您可以使用：

git config --list --show-origin | grep core.autocrlf

例如 git bash 在 C:/Program Files/Git/etc/gitconfig 中有自己的“全局”git 配置文件，但经常被忽视。

Answer 8

我遇到了同样的问题，并正在执行 git add 。 && git reset 正确恢复了所有行结尾。

Answer 9

这些消息是由于 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）。

（osx 之前的 cr 不会受到上述三个选项的影响。）

此警告何时出现（在 Windows 下）？

    – autocrlf = true 如果您的某个文件中有 unix 风格的 lf（= 很少），
    – autocrlf = input 如果您的某个文件中有 win 风格的 crlf（= 几乎总是） ,
    – autocrlf = false – 永远不会！

此警告是什么意思？

警告“LF will be returned by CRLF”表示您（具有 autocrlf=true) 将在提交签出周期后丢失你的 UNIX 风格的 LF（它将被 Windows 风格的 CRLF 取代）。 Git 不希望你在 Windows 下使用 unix 风格的 LF。

警告“CRLF will be returned by LF”表示您（拥有 autocrlf=input）在提交后将丢失 Windows 风格的 CRLF -checkout循环（将被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 (\Program Files\Git\etc\gitconfig< Windows 上为 /code>，Linux 上为 /etc/gitconfig）。另外还有（按以下顺序级联）：

   – “全局”（每用户）gitconfig 位于 ~/.gitconfig，又一个
    – “全局”（每用户）gitconfig 位于 $XDG_CONFIG_HOME/git/config 或 $HOME/.config/git/config 和
    – 工作目录中 .git/config 中的“本地”（每个存储库）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）：

    - 如果您打算在以下环境中使用此项目，请使用 core.autocrlf = true Unix 也是如此（并且不愿意配置您的编辑器/IDE 以使用 unix 行结尾），
   - 如果您打算仅在 Windows 下使用此项目（或者您已将编辑器/IDE 配置为使用unix 行结尾），
   -永远使用 core.autocrlf = input 除非你有充分的理由（例如< /em> 如果您在 Windows 下使用 unix 实用程序或者遇到 makefile 问题），

PS 安装适用于 Windows 的 Git 时选择什么？

如果您不打算使用任何项目在 Unix 下，不同意默认的第一个选项。选择第三个（按原样签出，按原样提交）。您将不会看到此消息。曾经。

PPS：我个人的偏好是将编辑器/IDE配置为使用unix风格的结尾，并将core.autocrlf设置为false。

更新（2022）

自 2018 年以来，git 可以 --renormalize 存储库根据需要修复现有的行结尾。

Answer 10

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 获取包含“输入”值的更新信息。

Answer 11

如果您已经签出代码，则文件已被索引。更改 Git 设置后，例如运行：

git config --global core.autocrlf input

您应该使用以下命令刷新索引

git rm --cached -r .

并使用以下命令重写 Git 索引

git reset --hard

：这将删除您的本地更改。在执行此操作之前考虑将它们隐藏起来。

---

来源：配置 Git 处理行结尾

Answer 12

git config core.autocrlf false

Answer 13

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

unix2dos filename

或

dos2unix -D filename

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

dos2unix -D filename 并不适用于所有操作系统。请检查此链接以了解兼容性。

如果由于某种原因您需要强制执行该命令，请使用 --force。如果显示无效，则使用 -f。

Answer 14

GitHub 文章在谈论这个话题时，经常会提到在线结尾。

我个人使用经常推荐的 core.autocrlf 配置设置的经历非常复杂。

我正在使用 Windows 和 Cygwin，在不同时间处理 Windows 和 Unix 项目。甚至我的 Windows 项目有时也使用 Bash shell 脚本，这需要 Unix (LF) 行结尾。

使用 GitHub 推荐的 Windows 的 core.autocrlf 设置，如果我查看一个 Unix 项目（它在 Cygwin 上完美运行 - 或者也许我正在为我在 Linux 服务器上使用的项目做出贡献），文本文件以 Windows (CRLF) 行结尾签出，从而产生问题。

基本上，对于像我这样的混合环境，将全局 core.autocrlf 设置为任何选项在某些情况下都不会很好地工作。此选项可能在本地（存储库）Git 配置上设置，但即使这样对于包含 Windows 和 Unix 相关内容的项目来说也不够好（例如，我有一个包含一些 Bash 实用程序脚本的 Windows 项目） 。

我发现的最佳选择是创建每个存储库的 .gitattributes 文件。 GitHub 文章 提到了它。

该文章中的示例：

# 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

需要设置的内容较多，但每个项目只需执行一次，并且任何操作系统上的任何贡献者在处理此项目时都应该不会遇到行结尾问题。

Answer 15

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

打开 ~/.gitconfig 文件并将 safecrlf 设置为 false：

[core]
       autocrlf = input
       safecrlf = false

这*将使它明显忽略行尾字符（无论如何，它对我有用）。

Answer 16

在 Vim 中，打开文件（例如： :e YOURFILEENTER），然后

:set noendofline binary
:wq

Answer 17

Windows 中的大多数工具也接受文本文件中的简单 LF。例如，您可以在名为“.editorconfig”的文件中控制 Visual Studio 的行为，其中包含以下示例内容（部分）：

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

仅原始 Windows 记事本不能与LF一起使用，但是有一些更合适的简单编辑器工具可用！

因此，您也应该在 Windows 中的文本文件中使用 LF。这是我的留言，强烈推荐！没有任何理由在 Windows 中使用 CRLF！

（同样的讨论是在C/++中的包含路径中使用\。它是牛粪便。使用#include带斜杠！，它是C/+ + 标准并且所有 Microsoft 编译器都支持它）。

因此，Git 的正确设置是：

git config core.autocrlf false

我的消息：忘记诸如 dos2unix 和 < a href="https://en.wikipedia.org/wiki/Unix2dos" rel="nofollow noreferrer">unix2dos。向您的团队澄清 LF 适合在 Windows 下使用。

Answer 18

我也有这个问题。

SVN 不进行任何行结尾转换，因此文件以完整的 CRLF 行结尾提交。如果您随后使用 git-svn 将项目放入 git 中，那么 CRLF 结尾会持续存在到 git 存储库中，这不是 git 期望的状态 - 默认情况下只有 unix/linux (LF) 行结尾 然后，当您在 Windows 上签出

文件时，autocrlf 转换会保持文件完好无损（因为它们已经具有当前平台的正确结尾），但是决定与签入文件是否存在差异的过程会执行比较之前的反向转换，导致将签出文件中的 LF 与存储库中意外的 CRLF 进行比较。

据我所知，您的选择是：

1. 在不使用 git-svn 的情况下将代码重新导入到新的 git 存储库中，这意味着行结尾会在初始 git commit --all
2. 设置 autocrlf 中进行转换为 false，并忽略行结尾不是 git 首选样式的事实在
3. 关闭 autocrlf 的情况下检查文件，修复所有行结尾，重新检查所有内容，然后再次打开它。
4. 重写存储库的历史记录，以便原始提交不再包含 git 不期望的 CRLF。 （有关历史重写的常见警告适用）

---

脚注：如果您选择选项#2，那么我的经验是，某些辅助工具（rebase、补丁等）无法处理 CRLF 文件，您将结束迟早会出现混合有 CRLF 和 LF（行结尾不一致）的文件。我不知道有什么办法可以两全其美。

Answer 19

从 ~/.gitattributes 文件中删除以下内容，

* text=auto

将首先阻止 Git 检查行结尾。

Answer 20

如何让 Git 忽略不同的行结尾

http://www.rtuin.nl/2013/02/how-to-make-git-ignore- Different-line-endings/< /a>（不工作）

您可以完全禁用 CRLF 行为，或者通过更改 .gitattributes 文件中的条目来按文件类型禁用 CRLF 行为。就我而言，我这样说：

• -crlf
  这告诉 Git 忽略所有文件的行结尾。并且不会更改工作目录中的文件。即使您将 core.autocrlf 设置为 true、false 或 input。

echo "* -crlf" > .gitattributes

在单独的提交上执行此操作，否则当您进行单个更改时，Git 可能仍然会看到整个文件已修改（取决于您是否更改了 autocrlf 选项）。

这个确实有效。 Git 将尊重混合行结尾项目中的行结尾，并且不会警告您。

Answer 21

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

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

当代码移动到另一个系统时，返回格式可能会被正确调整。我还认为 Git 足够聪明，可以保持二进制文件完整，而不是尝试将 LF 转换为 CRLF，比如 JPEG 文件。

总之，您可能不需要为这种转换过于担心。但是，如果您将项目存档为 tarball，其他编码员可能会喜欢使用 LF 行终止符而不是 CRLF。取决于您的关心程度（并且取决于您是否使用记事本），如果可以的话，您可能希望将 Git 设置为使用 LF 返回 :)

附录：CR 是 ASCII 代码 13，LF 是 ASCII 代码 10。因此，CRLF 是两个字节，而 LF 是 1 个字节。

Answer 22

它应该是：

警告：（如果您将其签出/或克隆到当前 core.autocrlf 为 true 的另一个文件夹，）LF 将被 CRLF 替换

该文件将在您的（当前）工作目录中保留其原始行结尾。

这张图应该能解释什么意思。

Answer 23

确保您已经安装了最新版本的 Git，

就像我在使用 Git（版本 2.7.1）时在之前的答案中所做的那样，git config core.autocrlf false，但它不起作用。

然后在升级 git 时（从 2.7.1 到 2.20.1）它就可以工作了。

Answer 24

在两个不同的操作系统（Linux 和 Windows）中使用“代码”时，CRLF 可能会导致一些问题。

我的 Python 脚本是在 Linux Docker 容器中编写的，然后使用 Windows 进行推送Git Bash。它警告我 LF 将被 CRLF 取代。我没有多想，但后来当我开始编写脚本时，它说：

/usr/bin/env: 'python\r': 没有这样的文件或目录

现在这是一个用于衍生的 \r 。 Windows 使用“CR” - 回车符 - 在“\n”之上作为换行符 - \n\r。这是你可能需要考虑的事情。

Answer 25

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

使用 --renormalize 添加有帮助，例如

git add --renormalize 。

来自 文档：

" 对所有跟踪的文件强制应用“干净”过程
再次将它们添加到索引中。改了之后这个很有用
core.autocrlf 配置或 text 属性以便更正
添加了错误的 CRLF/LF 行结尾的文件。此选项隐含 -u。”

Answer 26

我刚刚遇到了同样的错误。
在 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

虽然：

在某些项目中，我需要删除存储库并重新启动它。

Answer 27

1. 在 Notepad++ 中打开文件。
2. 转至菜单编辑 → EOL 转换。
3. 单击Windows 格式。
4. 保存文件。