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

unix2dos filename

or

dos2unix -D filename

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

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

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

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

unix2dos filename

or

dos2unix -D filename

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

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

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

在谈到这个话题时，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

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

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

尽管:

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

我也有这个问题。

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(不一致的行尾)的文件。我不知道有什么办法能两全其美。

这些消息是由于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可以根据需要重新规格化回购修复现有的行结束。