用CRLF代替LF
在Windows XP机器上使用bash运行git。 我从SVN导出我的项目，然后克隆一个裸仓库。
然后我将导出粘贴到裸存储目录，并做了一个：
git add -A 然后我得到一个消息列表说：
LF将被CRLF取代
这种转换的后果是什么？ 这是Visual Studio中的.NET解决scheme。
Git有三种处理行结束符的模式：
$ git config core.autocrlf # that command will print "true" or "false" or "input"
您可以通过向上述命令行添加true或false的附加参数来设置使用的模式。
如果core.autocrlf设置为true，这意味着每当你添加一个文件到git repo中，git认为它是一个文本文件，它就会把所有的CRLF行结束符转换成LF，然后将它存储在提交中。 每当你git checkout一些东西，所有的文本文件自动将他们的LF行结束符转换为CRLF结尾。 这允许使用不同行结束样式的平台开发项目，而不会提交非常嘈杂的声音，因为每个编辑器都会改变行结束样式，因为行结束样式总是LF一致的。
这种方便的转换的副作用，这就是你看到的警告是关于，如果你最初编写的文本文件有LF结尾而不是CRLF，它将像往常一样用LF存储，但是当选中后来它会有CRLF的结局。 对于正常的文本文件，这通常是好的。 在这种情况下，警告是“供您参考”，但如果git错误地将二进制文件评估为文本文件，这是一个重要的警告，因为git会破坏您的二进制文件。
如果core.autocrlf设置为false，则不会执行换行转换，因此将按原样检入文本文件。 这通常工作正常，只要所有的开发人员都在Linux上或全部在Windows上。 但在我的经验，我仍然倾向于获得混合行结束的文本文件，最终导致问题。
我的个人偏好是保持打开设置，作为Windows开发人员。
有关包含“input”值的更新信息，请参阅http://kernel.org/pub/software/scm/git/docs/git-config.html 。
这些消息是由于Windows上的core.autocrlf默认值不正确造成的。
autocrlf的概念是透明地处理行结束autocrlf转换。 它确实！
坏消息：值需要手动configuration。
好消息：每个git安装只能进行一次（每个项目设置也是可能的）。
autocrlf如何工作 ：
core.autocrlf=true: core.autocrlf=input: core.autocrlf=false: repo repo repo ^ V ^ V ^ V / \ / \ / \ crlf->lf lf->crlf crlf->lf \ / \ / \ / \ / \
提醒： crlf = win-style行尾标记， lf = unix-style。
请注意， cr （mac-style）不受上述三个选项中的任何一个的影响。
什么时候显示这个警告（在Windows下）
– autocrlf = true如果你有一个文件（= RARELY）有unix风格的lf ，
– autocrlf = input如果你有一个文件（=几乎总是）win风格的autocrlf ，
– autocrlf = false – 从不！
这个警告是什么意思
“ LF将被CRLFreplace ”的警告说你（ autocrlf = true ）在commit-checkout循环之后将失去你的unix风格的LF（它将被windows风格的CRLF所取代）。 Git不希望你在Windows下使用unix风格的LF。
“ CRLF将被replace为LF ”的警告说，你（有autocrlf = input ）将在一个提交结帐周期（它将被replace为unix风格的LF）后失去你的Windows风格的CRLF。 不要在windows下使用input 。
还有另一种显示autocrlf如何工作的方法
1) true: x -> LF -> CRLF 2) input: x -> LF -> LF 3) false: x -> x -> x
其中x是CRLF（窗口式）或LF（unix式），箭头代表
file to commit -> repository -> checked out file
怎么修
core.autocrlf缺省值在git安装过程中被选中并存储在系统范围的gitconfig（ %ProgramFiles(x86)%\git\etc\gitconfig ）中。 还有（按照以下顺序级联）：
– 位于~/.gitconfig “global”（per-user） ~/.gitconfig ，还有一个
– 在$XDG_CONFIG_HOME/git/config或$HOME/.config/git/config “global”（per-user）gitconfig和
– 工作目录中的.git/config “local”（per-repo）gitconfig。
因此，在工作目录中写入git config core.autocrlf来检查当前使用的值和
– 将autocrlf=false添加到系统范围的gitconfig＃per-system解决scheme
– git config --global core.autocrlf false ＃per-user解决scheme
– git config --local core.autocrlf false ＃per-project solution
道德 （对于Windows）：
– 如果你打算在Unix下使用这个项目，也可以使用core.autocrlf = true （并且不愿意configuration你的编辑器/ IDE使用unix行尾）
– 如果您打算只在Windows下使用该项目（或者您已经将您的编辑器/ IDEconfiguration为使用unix行结尾），请使用core.autocrlf = false ，
– 除非你有足够的理由，否则不要使用core.autocrlf = input （ 例如，如果你在windows下使用unix工具，或者遇到makefile问题），
PS 安装git for Windows时select什么？
如果你不打算在Unix下使用你的任何项目， 不要同意默认的第一个选项。 select第三个（ 原样签出，按原样提交 ）。 你不会看到这个消息。 永远。
PPS我个人偏好是将编辑器/ IDEconfiguration为使用Unix风格的结尾，并将core.autocrlf设置为false 。
PPPS警告： git config设置可以被gitattributes设置覆盖。
git config core.autocrlf false
如果您已经检出代码，则这些文件已经被编入索引。 更改你的git设置后，你应该刷新索引
git rm --cached -r .
并重新编写git索引
git reset --hard
在gitbash中 ， unix2dos和dos2unix都可用。 您可以使用以下命令执行UNIX（LF） – > DOS（CRLF）转换。 因此，你不会得到警告。
unix2dos filename
要么
dos2unix -D filename
但是，不要在任何现有的CRLF文件上运行这个命令，那么每隔一行就会得到空的换行符。
dos2unix -D filename名将不适用于每个操作系统。 请检查此链接的兼容性。
如果由于某种原因，你需要强制命令，然后使用--force 。 如果它说无效，那么使用-f 。
我认为@Basiloungas的答案是接近但过时（至less在Mac上）。
打开〜/ .gitconfig文件并将safecrlf设置为false
[core] autocrlf = input safecrlf = false
*会使它忽略行char的结尾，显然（为我工作，无论如何）。
在vim中打开文件（例如:e YOURFILE ENTER ），然后
:set noendofline binary :wq
我也有这个问题。
SVN不会做任何行结束转换，所以文件提交完整的CRLF行结束。 如果你使用git-svn把项目放到git中，那么CRLF的结尾会一直存放在git仓库中，这不是git希望自己进入的状态 – 缺省情况下只有unix / linux（LF）行结束入住。
当你在窗口签出文件时，autocrlf转换会保持文件不变（因为它们已经具有当前平台的正确结尾），但是决定与检入文件是否有区别的进程执行反向转换在比较之前 ，导致比较它认为签出文件中的LF与存储库中的意外CRLF。
据我所见，你的select是：
- 不使用git-svn将你的代码重新导入到一个新的git仓库中，这将意味着行结束符被转换成初始的git commit –all
- 将autocrlf设置为false，并忽略这样的事实，即行结束符不在git的首选样式中
- 用autocrlf关掉你的文件，修复所有的行结尾，检查所有的东西，然后再打开它。
- 重写您的存储库的历史logging，以便原始提交不再包含git不期望的CRLF。 （关于历史重写的通常注意事项适用）
脚注：如果你select了＃2选项，那么我的经验是，一些辅助工具（底座，补丁等）不能处理CRLF文件，并且迟早会用CRLF和LF混合的文件结束（不一致的行结局）。 我知道无法获得最好的两个。
从〜/ .gitattributes文件中删除下面的内容
* text=auto
会阻止git检查第一位的行尾。
谈论这个主题时，通常会提到GitHub关于行结尾的文章 。
我个人使用经常推荐的core.autocrlfconfiguration设置的经验非常混杂。
我在Cygwin上使用Windows，在不同的时间处理Windows和UNIX项目。 即使我的Windows项目有时也使用bash shell脚本，这需要UNIX（LF）行尾。
使用GitHub为Windows推荐的core.autocrlf设置，如果检出一个UNIX项目（在Cygwin上可以完美的工作，或者我正在为我在Linux服务器上使用的一个项目做出贡献），文本文件将被签出Windows（CRLF）行尾，造成问题。
基本上，对于像我这样的混合环境，在某些情况下，将全局core.autocrlf设置为任何选项都不会有效。 这个选项可能是在本地（版本库）gitconfiguration上设置的，但即使这样也不足以包含Windows和UNIX相关的东西（例如，我有一个带有一些bash实用程序脚本的Windows项目）。
我find的最佳select是创build每个资源库的.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上的git，但是…
在我看来，git正在转换返回格式以匹配正在运行的平台（Windows）。 CRLF是Windows中的默认返回格式，而LF是大多数其他操作系统的默认返回格式。
很可能，当代码被移到另一个系统时，返回格式将被正确调整。 我也认为git是足够聪明的，以保持二进制文件完好无损，而不是试图将LF转换成JPEG格式的CRLF。
总之，您可能不需要为此转换烦恼太多。 但是，如果你把你的项目归档为压缩包，那么编码人员可能会喜欢使用LF行结束符而不是CRLF。 根据你的关心程度（以及你不使用记事本），你可能想要设置git使用LF返回，如果你可以:)
附录：CR是ASCII码13，LF是ASCII码10.因此，CRLF是两个字节，而LF是1。
http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/
echo“* -crlf”> .gitattributes
做一个单独的提交或git可能仍然看到整个文件被修改，当你做一个单一的改变（取决于你是否改变了autocrlf选项）
这个真的有用。 Git会尊重混合行结束项目中的行结尾，而不是警告你。
它应该是：
警告:( 如果你检查出来/或克隆到另一个文件夹与您当前的core.autocrlf为
true），LF将被replace为CRLF该文件将在您的（ 当前 ）工作目录中具有其原始行尾。
这幅图应该解释它的含义。 
- 在记事本++中打开文件。
- 转到编辑/ EOL转换。
- 点击Windows格式。
- 保存文件。
OP的问题是Windows相关的，我不能使用其他人没有去目录，甚至在记事本+ +运行文件作为pipe理员没有工作..所以不得不走这条路线：
C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false
在GNU / Linux shell提示符下，dos2unix＆unix2dos命令允许您轻松地转换/格式化来自MS Windows的文件
