我有一个可以从Windows和OS X访问的Git存储库，我知道它已经包含了一些带有CRLF行结束符的文件。据我所知，有两种方法可以解决这个问题:
设置的核心。专制的虚伪无处不在， 按照这里的说明(在GitHub的帮助页面上有响应)将存储库转换为只包含LF行结束符，然后设置core。在Windows和OS x上的输入，将自专制设置为true。这样做的问题是，如果我在存储库中有任何二进制文件: 在gitattributes中没有正确地标记为二进制，并且 碰巧同时包含crlf和lf， 他们会被腐化。我的存储库可能包含这样的文件。
那么为什么我不应该关闭Git的行结束转换呢?网络上有很多关于核心的模糊警告。selff关闭了引起问题的开关，但很少有具体的问题;到目前为止，我唯一发现的是kdiff3不能处理CRLF结尾(对我来说不是问题)，以及一些文本编辑器有行结束问题(对我来说也不是问题)。
存储库是我的公司内部的，因此我不需要担心与具有不同的selff设置或行结束需求的人共享它。
还有什么我不知道的问题吗?
将selff设置为true的唯一具体原因是:
avoid git status showing all your files as modified because of the automatic EOL conversion done when cloning a Unix-based EOL Git repo to a Windows one (see issue 83 for instance) and your coding tools somehow depends on a native EOL style being present in your file: for instance, a code generator hard-coded to detect native EOL other external batches (external to your repo) with regexp or code set to detect native EOL I believe some Eclipse plugins can produce files with CRLF regardless on platform, which can be a problem. You code with Notepad.exe (unless you are using a Windows 10 2018.09+, where Notepad respects the EOL character detected).
除非你能看到必须处理原生EOL的特定处理，否则你最好把自专制设置为false (git配置——global core)。autocrlf假)。
注意，这个配置将是一个本地配置(因为配置不会从repo推到repo)
如果您希望所有克隆该repo的用户都使用相同的配置，请查看“git的最佳CRLF处理策略是什么?”，使用.gitattributes文件中的文本属性。
例子:
*.vcproj text eol=crlf
*.sh text eol=lf
注意:从git 2.8(2016年3月)开始，合并标记将不再在CRLF文件中引入混合行结束(LF)。 参见“让Git在其上使用CRLF”<<<<<<< HEAD“合并行”
更新2:
Xcode 9似乎有一个“特性”，它将忽略文件当前的行结束符，而只是使用默认的行结束符设置在插入到文件中时，导致文件的行结束符混合。
我很确定这个bug在Xcode 7中不存在;不确定Xcode 8。好消息是这个问题在Xcode 10中得到了修复。
在它存在的时候，这个错误在我在问题中提到的代码库中引起了少量的滑稽现象(直到今天使用的是selflf =false)，并导致了许多“EOL”提交消息，最终我写了一个git预提交钩子来检查/防止引入混合行尾。
更新:
注意:正如VonC所指出的，从Git 2.8开始，合并标记将不会为windows风格的文件引入unix风格的行结束符。
原:
我在这个设置中注意到的一个小问题是，当存在合并冲突时，git添加来标记差异的行没有Windows行结束符，即使文件的其余部分有，你最终可以得到一个混合行结束符的文件，例如:
// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>
这不会给我们带来任何问题(我想任何可以处理这两种类型的行结束符的工具也会合理地处理混合行结束符——当然我们使用的所有工具都是这样)，但是需要注意这一点。
我们发现的另一件事是，当使用git diff查看对具有Windows行结束符的文件的更改时，已添加的行将显示其回车符，如下所示:
// Not changed
+ // New line added in^M
+^M
// Not changed
// Not changed
*它并不真正配得上“问题”这个词。
我是一个。net开发人员，已经使用Git和Visual Studio很多年了。我强烈建议将行结束符设置为true。并且在您的Repository生命周期内尽早完成它。
也就是说，我讨厌Git改变我的行结束。源码控制应该只保存和检索我所做的工作，它不应该修改它。永远。但确实如此。
What will happen if you don't have every developer set to true, is ONE developer eventually will set to true. This will begin to change the line endings of all of your files to LF in your repo. And when users set to false check those out, Visual Studio will warn you, and ask you to change them. You will have 2 things happen very quickly. One, you will get more and more of those warnings, the bigger your team the more you get. The second, and worse thing, is that it will show that every line of every modified file was changed(because the line endings of every line will be changed by the true guy). Eventually, you won't be able to track changes in your repo reliably anymore. It is MUCH easier and cleaner to make everyone keep to true than to try to keep everyone false. As horrible as it is to live with the fact that your trusted source control is doing something it should not. Ever.
在我们的项目中，我们声明了将selff设置为输入值的必要性。以下是你可能会感兴趣的原因:
您的项目在Linux/Unix环境中运行，开发人员在Windows中编写代码。在推送期间，CRLF会自动转换为LF，因此你只需要在Unix服务器上签出Git repo，一切都会开箱运行。 有时开发人员使用WinSCP手动将配置从Windows计算机上传到服务器。这会导致Unix机器上的CRLF行结束和应用程序启动失败。“input”值部分地消除了这种情况的数量
我们不久前面临的问题是:
如果在DEV的机器上，行结束符被设置为CR(而不是CRLF)，那么在推送过程中，它们不会被转换为LF，而是在GIT存储库中保持CR。是否彻底检查行尾
