我每天都使用Windows，Mac OS X和Linux。我在所有这些环境中使用git，从具有不同选择的人们使用的repos中提取行结尾。
在我的情况下是否有设置core.autocrlf的明确建议？
答案 0 :(得分：35)
我建议，正如我在SO question中所做的那样，将其设置为false。
如果你可以避免修改任何eol（使用你的编辑器），那么最好用那些eol不变的方式推回你的工作（即“你发现它们”）。
答案 1 :(得分：15)
在这些讨论中经常没有提到的一个问题是：如果你在Windows上开发shell脚本（例如，在cygwin中）并使用CRLF（autocrlf = false）提交它们，它们将在* nix框中崩溃并出现无用的错误消息。 （其他脚本语言可能也有类似的情况。）在半个小时后，你会记住，然后dos2unix这些小流氓。如果您在混合环境中工作（例如从Windows部署到Linux服务器）并且您绝对想将autocrlf设置为false，那么请确保所有Windows编辑器都使用unix（lf）行结尾。否则设置autocrlf输入（和祈祷）。大多数21世纪Windows程序在没有1980年代早期的行式打印机CR的情况下都很舒服，因此最好将行结束设置为LF（unix）。
答案 2 :(得分：13)
GIT对于两个文本文件没有共同的SHA1，其中相同的文本，但二进制表示内的不同的行尾（EOL）机制。内容存储为blob，如果将另一个相同的副本解放到re-pository中，则重用（节省空间！）
GIT（设计者）采用的默认选择是尽可能使用* nix样式的EOL字符（仅限LF），这样对于相同的文本 content ，您将得到相同的SHA1 。 （可能是一个重要的考虑因素; - ）
因为内容/ blob不再记住用户的原始EOL选择（记住它现在可能存在于某个远程存储库中），Git必须做出一些关于如何重新创建原始用户文件的猜测（基于选项）（是CRLF还是是你（和你的工具）可以使用的那种简单的LF）。
通常建议本地每个用户（a）在提交到blob时转换为* nix LF结尾（因此所有人都会看到常见的SHA1 blob名称）（a / k / a the Right Thing），以及（b）在本地将重新创建选项设置为其本地系统设置，例如* nix（LF）或Windows（CRLF）等
为您的用户设置一些本地标准，并拥有一个大的'EOL / LF / CRLF＆amp;空白更正提交'，你会没事（再加上新用户的培训再培训）
您还可以确保您（每个用户）使用常见的空白区域调整设置，以便标签v空格和尾随空格不会导致更多diff条不便！