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

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

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

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

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

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”值的更新信息。

我也有这个问题。

SVN不执行任何行结束转换，因此提交文件时保留CRLF行结束。如果您使用git-svn将项目放入git中，那么CRLF结束符将持续到git存储库中，这不是git希望自己处于的状态——默认情况是只检入unix/linux (LF)行结束符。

当您在windows上签出文件时，selflf转换会保持文件不变(因为它们已经具有当前平台的正确结尾)，但是，决定签入文件是否存在差异的进程会在比较之前执行反向转换，从而将它认为是签出文件中的LF与存储库中的意外CRLF进行比较。

在我看来，你的选择是

Re-import your code into a new git repository without using git-svn, this will mean line endings are converted in the intial git commit --all Set autocrlf to false, and ignore the fact that the line endings are not in git's preferred style Check out your files with autocrlf off, fix all the line endings, check everything back in, and turn it back on again. Rewrite your repository's history so that the original commit no longer contains the CRLF that git wasn't expecting. (The usual caveats about history rewriting apply)

---

注:如果你选择选项2，那么我的经验是，一些辅助工具(rebase, patch等)不能处理CRLF文件，你迟早会得到混合了CRLF和LF(不一致的行尾)的文件。我不知道有什么办法能两全其美。

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

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

unix2dos filename

or

dos2unix -D filename

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

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

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

在Vim中，打开文件(例如::e YOURFILEENTER)，然后

:set noendofline binary
:wq

从~/。gitattributes文件,

* text = auto

将防止Git首先检查行结束符。

在notepad++中打开文件。 进入菜单编辑→EOL转换。 单击Windows格式。 保存文件。

这些消息是由于core的默认值不正确造成的。在Windows上自定义。

selflf的概念是透明地处理行结束符转换。确实如此!

坏消息:该值需要手动配置。

好消息:每个Git安装只需要执行一次(每个项目设置也可以)。

selff如何工作:

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

     repository               repository               repository
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \
   /            \           /            \           /            \

这里crlf = win-style的行尾标记，lf = unix-style(自Mac OS X以来也用于Mac)。

(pre-osx cr不受上述三个选项中的任何一个的影响。)

这个警告什么时候显示(在Windows下)?

如果你的一个文件中有unix风格的lf (= RARELY)， 如果你有win-style的crlf在你的一个文件(=几乎总是)， - selflf = false - NEVER!

这个警告是什么意思?

警告“LF将被CRLF取代”表示您(拥有自自LF =true)将在提交签出周期后失去unix风格的LF(它将被windows风格的CRLF取代)。Git并不期望你在Windows下使用unix风格的LF。

警告“CRLF将被LF取代”表示您(拥有自自LF =input)将在提交签出周期后失去windows风格的CRLF(它将被unix风格的LF取代)。不要在Windows下使用输入。

这是另一种显示selff如何工作的方法

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的默认值。在Git安装过程中选择自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义。还有(按以下顺序级联):

-“global”(每个用户)gitconfig位于~/。Gitconfig，另一个 -“global”(每个用户)gitconfig $XDG_CONFIG_HOME/git/config或$HOME/配置/ git /配置和 -“local”(per-repo) gitconfig在工作目录的.git/config。

所以，写git config core。在工作目录中查看当前使用的值和

- git配置——系统核心。自专制错误#每系统解决方案 - git配置全局核心。专制错误#每用户解决方案 - git配置——local core。自专制错误#每个项目解决方案

警告

- git配置设置可以被gitattributes设置覆盖。 - CRLF -> lf转换仅在添加新文件时发生，已经存在于repo中的CRLF文件不受影响。

寓意(适用于Windows):

-使用核心。如果你计划在Unix下使用这个项目(并且不愿意将你的编辑器/IDE配置为使用Unix行结束符)，自专制语句= true， -使用核心。如果你计划只在Windows下使用这个项目(或者你已经将你的编辑器/IDE配置为使用unix行结束符)，自专制语句= false， -永远不要使用核心。除非你有一个很好的理由(例如，如果你在Windows下使用unix实用程序，或者如果你遇到makefiles问题)，

安装Git for Windows时选择什么?

如果您不打算在Unix下使用任何项目，请不要同意默认的第一个选项。选择第三个(按原样签出，按原样提交)。你不会看到这条消息。永远。

PPS:我的个人偏好是将编辑器/IDE配置为使用unix风格的结尾，并设置核心。专制到虚伪。

更新(2022)

自2018年以来，git可以根据需要重新规格化回购修复现有的行结束。

git config core.autocrlf false

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

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

[core]
       autocrlf = input
       safecrlf = false

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

如何使Git忽略不同的行结束

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/(不工作)

您可以完全禁用CRLF行为，或者通过更改.gitattributes文件中的条目来禁用每个文件类型。在我的例子中，我写的是: crlf 这告诉Git忽略所有文件的行结束符。并且不会更改工作目录中的文件。即使你有核心。自专制设置为true, false或输入。

echo "* -crlf" > .gitattributes

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

这个真的有用。Git将尊重混合行结束项目中的行结束符，而不会就此警告您。

OP的问题是与windows相关的，我无法使用其他的目录，甚至无法在notepad++中运行文件，因为管理员无法工作…

所以不得不走这条路:

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

如果您已经签出了代码，那么文件就已经建立了索引。在更改Git设置后，运行以下命令:

git config --global core.autocrlf input

您应该使用

git rm --cached -r .

并重写Git索引

git reset --hard

注意:这将删除您的本地更改。在你这么做之前考虑把它们藏起来。

---

来源:配置Git处理行结束符

在谈到这个话题时，GitHub上一篇关于行尾的文章经常被提到。

我个人使用经常推荐的核心的经验。自专制的配置设置非常复杂。

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

使用GitHub推荐的核心。如果我签出一个Unix项目(它在Cygwin上工作得很好-或者我正在为一个我在Linux服务器上使用的项目做贡献)，文本文件会用Windows (CRLF)行结束符签出，这会产生问题。

基本上，对于像我这样的混合环境，设置全局核心。在某些情况下，任意选择都不能很好地工作。这个选项可以在本地(存储库)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

要设置的东西更多一些，但是每个项目都要设置一次，任何操作系统上的任何贡献者在处理这个项目时都应该不会遇到行结束符的问题。

它应该是:

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

这张图可以解释它的意思。

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

---

点击右下角的CRLF:

在顶部的下拉菜单中选择LF:

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

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

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

现在这个r对你们来说是ramification的意思。Windows在“\n”上方使用“CR”-换行符- \n\r。这是你可能需要考虑的事情。

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

我在之前的回答中，git配置核心。在使用Git(2.7.1版)时，自专制错误，但它不工作。

然后，当升级git(从2.7.1到2.20.1)时，它就可以工作了。

Windows中的大多数工具也接受文本文件中的简单LF。例如，你可以在一个名为'的文件中控制Visual Studio的行为。Editorconfig '使用以下示例内容(部分):

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

只有原来的Windows记事本不能使用LF，但有一些更合适的简单编辑器工具可用!

因此你也应该在Windows的文本文件中使用LF。这是我的信息，强烈推荐!没有任何理由在窗口中使用CRLF !

(同样的讨论是在C/ c++中使用\ in include路径。这是牛的粪便。使用#include <pathTo/myheader.h> +斜杠!它是C/++标准，所有微软编译器都支持它)。

因此Git的正确设置是:

git config core.autocrlf false

我想说的是:忘记dos2unix和unix2dos这类思维陈旧的程序吧。在您的团队中阐明LF适合在Windows下使用。

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

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

Git添加——重新规范化。

从文档中可以看到:

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

我也有同样的问题，做git添加。&& git重置恢复所有行结束正确。

我只是犯了同样的错误。 这是在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

尽管:

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

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