我有一个从Windows和OS X访问的Git存储库，我知道已经包含一些带有CRLF行结尾的文件。据我所知，有两种方法可以解决这个问题：

他们会被腐化。我的存储库可能包含这些文件。

那么为什么我不应该关闭Git的行结束转换呢？网上有很多关于core.autocrlf关闭导致问题的模糊警告，但很少有具体问题;到目前为止我唯一发现的是kdiff3无法处理CRLF结尾(对我来说不是问题)，而且一些文本编辑器有行结束问题(对我来说也不是问题)。

存储库是我公司的内部存储库，因此我不需要担心与具有不同autocrlf设置或行结束要求的人共享它。

是否有任何其他问题只是留下我不知道的行结尾？

将autocrlf设置为true的唯一具体原因是：

• 避免git status将所有文件显示为modified，因为在将基于Unix的EOL Git存储库克隆到Windows时会自动执行EOL转换(例如，请参见问题83)
• 并且您的编码工具以某种方式依赖于文件中存在的本机EOL样式：
  • 例如，代码生成器硬编码以检测本机EOL
  • 其他外部批次(在您的仓库外部)使用正则表达式或代码集来检测本机EOL
  • 我相信一些Eclipse插件可以在平台上生成带有CRLF的文件，这可能是个问题。
  • 您使用Notepad.exe进行编码(除非您使用的是Windows 10 2018.09+，其中Notepad尊重检测到的EOL字符)。

除非您能看到必须处理原生EOL的特定处理，否则最好将autocrlf留给false。

请注意，此配置将是本地配置(因为配置不会从repo推送到repo)

如果你想为克隆那个repo的所有用户提供相同的配置，请使用.gitattributes文件中的text属性查看"使用git最好的CRLF处理策略是什么？"。

注意：启动git 2。8(2016年3月)，合并标记将不再在CRLF文件中引入混合行结尾(LF)。
请参阅"让Git在其上使用CRLF"<<<<<<< HEAD"合并线"

我是.NET开发人员，多年来一直使用Git和Visual Studio。我的强烈建议是设定行结束为真。并在存储库的生命周期中尽早完成。

话虽如此，我讨厌Git改变我的行结尾。源代码控制应该只保存和检索我做的工作，它不应该修改它。永远。但确实如此。

如果你没有让每个开发人员都设置为true会发生什么，那么ONE开发人员最终会设置为true。这将开始在您的仓库中将所有文件的行结尾更改为LF。当用户设置为false检查时，Visual Studio会警告您，并要求您更改它们。你会很快发生两件事。一，你会得到越来越多的警告，你的团队越大，得到的就越多。第二个也是最糟糕的是，它会显示每个修改过的文件的每一行都被更改(因为每一行的行结尾都会被真正的人改变)。最终，您将无法再可靠地跟踪回购中的更改。让每个人都保持真实，比试图让每个人都虚假更容易和更清洁。尽管你可靠的源代码控制正在做一些不应该做的事情，但这很可怕。永远。

更新：

注意：正如VonC所指出的，从Git 2.8开始，合并标记不会将Unix样式的行结尾引入Windows样式的文件。

原版的：

我注意到这个设置的一个小小问题是，当存在合并冲突时，git添加的行添加标记差异没有Windows行结尾，即使文件的其余部分有，也可以结束带有混合行结尾的文件，例如：

这并没有给我们带来任何问题(我想任何可以处理这两种类型的行结尾的工具也会对混合行结尾做出明智的处理 - 当然我们使用的都是这样)，但这是需要注意的事情。

我们发现的另一件事是，当使用git diff查看具有Windows行结尾的文件的更改时，已添加的行显示其回车符，因此：

_{*这个词并不值得："问题"。}