我正在寻找根据某些用例使用的正确设置，但找不到任何描述相同的来源。因此，我问这个问题是为了给任何寻找 git 的 autocrlf 选项的正确设置的人提供解决方案。
用例 1：我在 Mac 上，其他开发人员都在 Windows 上。在我加入之前，他们正在管理源代码。
用例 2：我在 Windows 上，其他开发人员都在 Mac 上。在我加入之前，他们正在管理源代码。
用例 3：我在 Linux 上，其他开发人员都在 Windows 上。在我加入之前，他们正在管理源代码。
用例 4：我在 Windows 上，其他开发人员都在 linux 上。在我加入之前，他们正在管理源代码。
用例 5：我在 Linux 上，其他开发人员都在 Mac 上。在我加入之前，他们正在管理源代码。
用例 6：我在 Mac 上，其他开发人员都在 Linux 上。在我加入之前，他们正在管理源代码。
我应该使用 git core.autocrlf 的什么设置？
编辑： 为什么这个问题与许多类似问题不重复：
所有其他问题及其答案都提供了所需的事实和知识，让读者有很多工作要做。这个问题旨在针对特定场景询问具体答案。
简单的：
git config core.autocrlf false
（适用于所有和任何场景）
core.autocrlf是一个config，这意味着它不会与 repo 一起推送或克隆：它必须由用户设置。
这是在回购级别处理 eol 的传统方式。
您想要使用的（根据您的场景添加或修改）是 gitattributescore.eol指令。
.gitattributes是一个可以像任何其他文件一样在 git repo 中管理的文件。一旦您同意 eol 策略，该策略将在每个克隆中强制执行。core.eol需要为文件或文件组设置指令（与全局存储库范围的配置相反core.autocrlf）对于异构环境，core.eol（仅适用于您认为有问题的文件）应该是native（如果您怀疑您的编辑器坚持使用系统 eol 而不是使用文件中已经存在的文件）。
有关更多信息，请参阅“注意行尾”。
别担心core.autocrlf；在根目录中添加一个.gitattributes文件并将以下行放入：
* text=auto
这将导致 git 在提交时自动将所有行尾转换为 LF，并且（对于 Windows 机器）在结帐时将行尾转换为 CRLF。
请注意，对于现有开发人员在 Windows 上的用例 1 和 3，添加此行.gitattributes可能会使您看起来突然有大量更改要提交。那是因为您在存储库中有很多带有 CRLF 的文件，而 git 知道它必须将它们全部转换为 LF。继续提交这些更改，即使看起来并没有真正改变。
另一件需要注意的事情是，如果每个人都在同一个操作系统上，那么我什至不会在转换行结尾时搞乱；在这种情况下，将该行* -text放入您的.gitattributes文件中，以免发生转换。