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

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

:set noendofline binary
:wq

如何使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将尊重混合行结束项目中的行结束符，而不会就此警告您。

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

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

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

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

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

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

我也有这个问题。

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