根据.gitattributes 的文档，text启用行尾规范化：
text在路径上设置 text 属性可启用行尾规范化并将路径标记为文本文件。行尾转换无需猜测内容类型即可进行。
根据相同的文档，eol=lf还将规范换行符：
eol此属性设置要在工作目录中使用的特定行结束样式。它可以在没有任何内容检查的情况下实现行尾规范化，有效地设置文本属性。
给出的示例将它们混合在同一个文件中的事实似乎暗示它们之间存在一些（也许是细微的）差异：
*.txt text
*.vcproj eol=crlf
*.sh eol=lf
*.jpg -text
此外，似乎没有任何地方明确声明它们是相同的，或者text是简写——eol=lf尽管情况似乎如此。我能找到的最接近这种声明的是我上面引用的内容，它说“有效设置文本属性”。但是这个词实际上似乎稍微后退了一点，好像它实际上并没有设置文本属性，而只是或多或少地设置了它，或者具有几乎相同的效果。
确切地说，这两者之间的区别是什么？（或者text只是常见用例的简写？）您是否有任何理由将两者混合在一个.gitattributes文件中？
或者：确实text需要 Git 猜测您需要哪种换行符，而eol（显然）指定？
基于这篇文章: `.gitattributes`文件中`text = auto`的目的是什么？如果.gitattributes文件中包含以下内容,则 行结尾将转换为LF以用于文本文件:
* text=auto
我刚刚在本地存储库上测试过:
$ git add -A
warning: LF will be replaced by CRLF in [bla]/.gitattributes.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in [bla]/.gitignore.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in [bla]/README.md.
The file will have its original line endings in your working directory.
warning: LF …我正在搜索根据某些用例使用的正确设置,但找不到任何描述相同的来源.因此,我要求这个问题作为任何寻找git的autocrlf选项正确设置的人的解决方案.
使用案例1:我在Mac上,其他开发人员都在Windows上.他们在我加入之前管理源代码.
使用案例2:我在Windows上,其他开发人员都在Mac上.他们在我加入之前管理源代码.
用例3:我在Linux上,其他开发人员都在Windows上.他们在我加入之前管理源代码.
用例4:我在Windows上,其他开发人员都在Linux上.他们在我加入之前管理源代码.
使用案例5:我在Linux上,其他开发人员都在Mac上.他们在我加入之前管理源代码.
使用案例6:我在Mac上,其他开发人员都在Linux上.他们在我加入之前管理源代码.
我应该使用什么设置的git core.autocrlf？
编辑: 为什么这个问题不是许多类似问题的重复:
所有其他问题及其答案提供了所需的事实和知识,这使得读者需要做很多事情.这个问题旨在询问具体方案的具体答案.
在一个相对较大的项目中，使用签出CRLF和提交LF的策略。为此，我的系统使用：
git config --global core.autocrlf true
但是，当提交文件（在本例中为.gitattributes文件）时，会返回警告：
LF would be replaced by CRLF in .gitattributes
文件.gitattributes本身包含该行* text=auto !eol，并且文件本身使用 LF 行结尾。
为什么会发生这种情况？为什么 Git 告诉我要小心，因为它会将 LF 转换为 CRLF，即使我希望此文件在存储库中以 LF 结尾进行规范化？
我一定错过了一些完全明显的东西，因为我已经经历过：
还有更多，但这仍然没有像我想象的那样工作。
我已经阅读了有关如何使用 git 命令从存储库中删除忽略文件中的文件的信息：将目录添加到 .gitignore 后从远程存储库中删除。
我将 Visual Studio 2019 与 Azure DevOps 中的存储库一起使用。我使用了以下步骤：
git rm -r --cached .
这告诉 git 停止跟踪所有内容，现在我的所有文件在“暂存更改”中显示为已删除，而在“更改”中显示为添加的文件数量较少。这看起来不错。我假设被忽略的文件不会再次添加回来，所以当我提交这些添加时，所有原本应该被忽略的文件都将在服务器上被删除。我猜这与行尾有关，但几乎不可能查看更改。有没有办法阻止我使用这个过程时发生的空白变化？或者扭转空白变化？或者告诉 git 只检查删除？
TLDR 答案（来自 VonC）：
git rm -r --cached .
git config --global core.autocrlf false
git add --renormalize .
git add .
git commit
我对git config的core.eol,core.autocrlf,core.safecrlf有点困惑.
http://git-scm.com/docs/git-config
我正在使用Ubuntu和Widows.
我之前有过^ M和其他问题.
谁能为这个问题建议最好的git配置设置？
提前致谢.
我正在使用GIT gui.我在文件夹中的几个文件中看到此错误.我有两个选择按钮 - 解锁索引并继续.我不明白按钮的作用.我看到其他SO帖子告诉我忽略警告,但他们没有提到如何在GUI中执行此操作.请告诉我应按哪个按钮以及为什么.谢谢.
这是错误消息示例 -
Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui.
warning: LF will be replaced by CRLF in gen/com/click4tab/pustakalpha/BuildConfig.java.
The file will have its original line endings in your working directory.
(repeat above messages for other files)
我正在尝试处理 .gitattributes 中没有扩展名的文件：
* text=auto
*. eol=lf
.py eol=lf
*.显然没有帮助。git check-attr --all -- ./foo输出：
./foo: 文本: 自动
如何才能做到这一点？
我已经阅读了这个答案中讨论的 Git 文档（LF 将被 git 中的 CRLF 取代 - 那是什么，它很重要吗？）但我不明白这对我的情况意味着什么。
我有 LF 文件，这些文件是由工具引入到我在 Windows 上的 git checkout 中的。当我尝试提交它们时，我收到了警告warning: LF will be replaced by CRLF in [file]。
git config core.autocrlf在这台机器上是真的。反正我答应了。Windows 上的行尾仍然是 LF。然后我在git config core.autocrlf似乎没有设置的 Linux 机器上检查了该文件。我检查了那里的行尾，它们也是 LF。
所以我不明白的是，哪里说LF将被CRLF取代？这是否意味着，下次我对文件进行更改（由另一台机器上的某人提交）时，行尾将被转换？
另外 - Git 在其内部存储库中使用什么行结尾？
在与使用不同操作系统的人一起工作时，由于行结束，我遇到了合并冲突问题。我在 Windows 上工作，我的同事在 Mac 上工作。当他推送他的更改时，有时他没有处理过的文件会在 diff 中显示为已更改，因为现在^M每个文件上都会显示行尾。这导致了合并冲突。我在 Git 文档中阅读了以下内容：
当您将文件添加到索引时，Git 可以通过将 CRLF 行结尾自动转换为 LF 来处理此问题，反之亦然，当它检出代码到您的文件系统时。您可以使用 core.autocrlf 设置打开此功能。如果您使用的是 Windows 计算机，请将其设置为 true？—？这会在您检出代码时将 LF 结尾转换为 CRLF：
$ git config --global core.autocrlf true 如果你在使用 LF 行尾的 Linux 或 macOS 系统上，那么你不希望 Git 在检出文件时自动转换它们；但是，如果意外引入了带有 CRLF 结尾的文件，那么您可能需要 Git 修复它。您可以通过将 core.autocrlf 设置为输入来告诉 Git 在提交时将 CRLF 转换为 LF，而不是相反：
$ git config --global core.autocrlf input 这个设置应该让你在 Windows 结账中使用 CRLF 结尾，但在 macOS 和 Linux 系统以及存储库中使用 LF 结尾。
这是有道理的，但我仍然不清楚这些文件是如何在 repo 中实际提交的。例如，如果他在他的系统上创建一个文件，它会有所有的LF行结尾，对吗？因此，当他提交时，我认为这些行结尾保持原样。据我所知，当我拉动时，我的autocrlf存在true会用CRLF行尾检查它们。（我收到警告warning: …