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

点击右下角的CRLF:

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

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下使用。

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

unix2dos filename

or

dos2unix -D filename

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

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

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

我也有这个问题。

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

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

git config --global core.autocrlf input

您应该使用

git rm --cached -r .

并重写Git索引

git reset --hard

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

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

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