根据用例正确设置 git autocrlf答案

【问题标题】：Correct setting for git autocrlf as per use case根据用例正确设置 git autocrlf
【发布时间】：2016-05-08 08:31:42
【问题描述】：

我正在寻找根据某些用例使用的正确设置，但找不到任何描述相同的来源。因此，我问这个问题是为了给任何寻找 git 的 autocrlf 选项正确设置的人提供解决方案。

用例 1：我在 Mac 上，其他开发人员都在 Windows 上。在我加入之前，他们正在管理源代码。

用例 2：我在 Windows 上，其他开发人员都在 Mac 上。在我加入之前，他们正在管理源代码。

用例 3： 我在 Linux 上，其他开发人员都在 Windows 上。在我加入之前，他们正在管理源代码。

用例 4： 我在 Windows 上，其他开发人员都在 linux 上。在我加入之前，他们正在管理源代码。

用例 5：我在 Linux 上，其他开发人员都在 Mac 上。在我加入之前，他们正在管理源代码。

用例 6：我在 Mac 上，其他开发人员都在 Linux 上。在我加入之前，他们正在管理源代码。

我应该使用 git core.autocrlf 的什么设置？

编辑： 为什么这个问题与许多类似问题不同：

所有其他问题及其答案都提供了所需的事实和知识，让读者有很多事情要做。这个问题旨在针对特定场景询问具体答案。

【问题讨论】：

【解决方案1】：

简单：

 git config core.autocrlf false

（适用于所有和任何场景）

core.autocrlf 是一个配置，这意味着它不会与 repo 一起推送或克隆：它必须由用户设置。

这是在回购级别处理 eol 的传统方式。

您想要使用的（根据您的场景添加或修改）是 gitattributes core.eol directives。

.gitattributes is a file 可以像任何其他文件一样在 git repo 中进行管理。一旦您就 eol 政策达成一致，该政策将在每次克隆时强制执行。
您可以根据需要为一个文件或一组文件设置 core.eol 指令（而不是全局存储库范围的配置 core.autocrlf）

对于异构环境，core.eol（仅适用于您认为有问题的文件）应该是native（如果您怀疑您的编辑坚持使用系统 eol 而不是使用文件中已经存在的那个）。

更多信息，请参阅“Mind the End of Your Line”。

【讨论】：

【解决方案2】：

不用担心core.autocrlf;在根目录下添加.gitattributes文件，并在其中放入以下行：

* text=auto

这将导致 git 在提交时自动将所有行尾转换为 LF，并且（对于 Windows 机器）在结帐时将行尾转换为 CRLF。

请注意，对于现有开发人员在 Windows 上的用例 1 和 3，将此行添加到 .gitattributes 可能会使您看起来突然有大量更改要提交。那是因为您在存储库中有很多带有 CRLF 的文件，而 git 知道它必须将它们全部转换为 LF。继续提交这些更改，即使看起来并没有真正改变。

要注意的另一件事是，如果每个人都在同一个操作系统上，那么我什至不会搞乱转换行尾；在这种情况下，将* -text 行放入您的.gitattributes 文件中，这样就不会发生转换。

【讨论】：