我们有一个从 subversion 导出到 git 的存储库。此存储库供 Mac、Linux 和 PC 用户使用。不用说，行尾是一团糟。有些文件以 CRLF、LF 或 CR 结尾，有些文件混合了两个或三个文件。
添加autocrlf = true 似乎可以稍微解决问题。然而，差异有时会很奇怪，即对文件进行单行编辑会使差异中的所有行看起来都发生了变化（我认为这是由于文件的行尾都被重写了），有时一行编辑到文件正常工作。
有没有网站，或者有人可以解释一下我们如何解决这个问题吗？是否有我们必须设置的 git 设置，或者我们是否必须对所有文件进行批量更新以具有特定的行结尾或什么？
任何帮助将不胜感激，因为它非常混乱！
（下面的stackoverflow post 似乎可能会有所帮助，尽管它不能回答当我们有另一个 mac 或 pc 或 linux 用户提交另一个补丁时会发生什么）
【问题讨论】：
标签： git
你会感兴趣这个相关的 SO 问题：
Trying to fix line-endings with git filter-branch, but having no luck
这里是 a link 来自 Github 的类似建议。
此外，正如 Greg Hewgill 的帖子中提到的，明智的做法是验证未来的提交者是否使用正确处理新行结束策略的编辑器。
当您说“添加 autocrlf = true 似乎可以稍微解决问题”时。我假设这是使用.gitattributes 完成的。
【讨论】：
git config --global core.autocrlf true，如果他们不使用它就提交，然后打他们？
.gitattributes 的美妙之处在于可以将文件推送到存储库。如果 core.autocrlf 在文件中设置并推送，那么我相信它应该在任何克隆中强制行结尾。但是，我不确定是否需要新的克隆，或者每个提交者是否需要遵循 Github 上给出的建议。
我会尽可能地尝试标准化一个通用的行结尾，以便在项目中的所有源文件中使用。一个不错的选择可能只是 LF，但是我会检查开发人员使用的编辑器是否能正确和正确地处理您选择的公共行结尾。 （在这种情况下，明智的意思是不要仅仅因为用户更改了一行就更改文件中的每一行。）
您可能需要进行一项大型清理工作并进行一次大型提交，将所有文件行结尾更改为您选择的标准结尾。这会很尴尬，但可能不像保持各种不同的行尾那样尴尬。
【讨论】：