我们什么时候[应该]使用[这些设置中的任何一个]？
我的偏好是never。另一方面，我也不在 Windows 上工作。 :-) 但是，如果您通读下面的所有文字，您会发现如果我这样做，我仍然会说“从不”。 （即使您正在共享一些不允许您创建的上游存储库.gitattributes文件，您可以使用每个存储库$GIT_DIR/info/attributes文件在您自己的克隆中。）
[有什么不同？]
为了弄清楚区别，我们首先需要注意：
- 什么是转化？ Git 可以进行哪些转换？
- Git 什么时候可以进行转换？什么时候willGit 做转换吗？
- Git 如何判断一个文件是“文本”？
转换、输入和输出：清洁和污迹
第一部分非常简单，尽管它给新手带来了自己的绊脚石。 Git 可以做任何你想要的转换，因为它有 Git 所说的清洁过滤器 and 污迹过滤器.
A 清洁过滤器是您（是的，您！）可以自己编写的转换，当您使用以下命令将文件从工作树复制到索引时，Git 将应用该转换git add或同等学历。也就是说，假设您将一个文件检出到工作树中，并且您对其进行编辑，或完全替换它，或对其运行某些程序以对其进行更改。您可能想要提交该文件的新版本。所以你必须跑git add path将文件从工作树复制回索引。 （请记住，Git 会根据index，而不是来自工作树中的内容。这就是为什么你必须不断git add始终保存您的文件：Git 不会自动从工作树复制到索引。）
每当你跑步时git add file，Git 会在进入时“清理”文件。这是一个输入转换.
相反，你可以自己写污迹过滤器，这是您在数据到来时对数据进行归档的操作outGit（从索引中，到你的工作树中）。由于 Git 内的所有文件（包括索引中的文件）都已准备好复制到next提交，每个文件都采用某种特殊的、内部的、仅限 Git 的格式must转换为所有常规计算机程序可以处理的正常格式。每当您提取文件时to在工作树中，Git 会在退出时“弄脏”（弄脏）文件。那是一个输出转换.
Git 有时会进行输入转换，而不实际将文件复制到索引中：特别是，如果您运行git diff必须将工作树文件与同一文件的索引或提交副本进行比较，即inside存储库已经被“清理”，而工作树中的存储库则全部“弄脏”和“肮脏”。在它们都处于相同状态之前无法进行比较，因此 Git 会在进行比较之前“清理”工作树。
内置的行结束转换
Git 有两个内置转换。一种是在清理时使用，即当文件从工作树复制到 Git（复制到索引）时。这将 CRLF 行结尾替换为仅换行符、Linux 风格的行结尾。另一个是在涂抹时使用的，即从 Git 中复制文件时。这个将仅换行符的 Linux 风格的行结尾替换为......好吧，某物.
这个“东西”在哪里core.eol你可以让 Git 用 CRLF 替换换行符，如果你在 Windows 上并且你的程序要求行以 CRLF 结尾，那么你可能会想要这样做，但你也与在 Linux 上工作的人一起工作，这要求行以仅 LF 换行样式结尾结束。
或者，您可以让 Git 用仅 LF 替换换行符...但这不是替代品，因为换行符is换行符“LF”。称其为替代品有点愚蠢。
你可以让 Git 根据你的系统选择结尾，这样一种配置，core.eol set to native，适用于both Linux and视窗。
Git 有点狡猾：当它要用 LF“替换”LF（这毕竟不是替换）时，它往往什么都不做——甚至不检查任何东西——因此速度更快。看起来你可能永远不会注意到这一点，除了core.safecrlf设置要求 Git 检查事物。这safecrlf事情涉及一些猜测，并且意味着过度保护并让你设置.gitattributes如果您要进行转换，请更改设置，这样就不会损坏任何二进制文件。
二进制文件：Git 如何判断文件是文本？
有些文件，例如.jpg例如，图像只是not text并且应该never have any他们的数据以“文本式”方式修改。它们需要使用图像操作代码进行操作，而不是使用文本编辑器或 Git 内置转换的笨拙工具行。因此 Git 需要一种方法来区分text文件，应该应用这些行结束转换，来自non-text or binary files.
如果你不告诉 Git 哪些文件是哪些，它就必须猜测。 Git用来猜测的方法是not看看.jpg or .txt扩展名——这不适用于名为README， 例如。相反，Git 会查看文件中存储的数据，并根据它“看起来像文本”还是“看起来二进制”进行猜测。
正如你可以想象的那样，这个猜谜游戏并不完美。它可能对你有用，但如果不起作用，你可以而且应该tellGit 哪些文件是哪些。您可以通过创建一个名为的文件来完成此操作.gitattributes. In .gitattributes，您可以列出特定的文件名，例如README，或路径名模式，如*.txt and *.jpg，作为“绝对文本”或“绝对二进制”。你这样做text or -text。你还可以告诉 Git：guess!你这样做auto:
*.txt text
*.jpg -text
guess auto
你永远不应该使用auto如果你能帮忙的话。
如果您从未让 Git 进行任何转换，则不必执行此操作。告诉 Git 哪些文件是文本文件、哪些文件是二进制文件的目的是确保 Git 正确进行转换，并且只有在进行转换时才需要这样做。因此，如果您避免使用 Windows，则不必创建.gitattributes并列出您的文件。无论如何，创建它并没有什么坏处，但如果你确实创建了它，你应该尝试让它覆盖你的所有文件，这样 Git 就不必猜测。
现在我们知道了这一切，我们可以理解文档了
考虑到上述内容，我们可以看到什么core.autocrlf通过咨询来做the git config文档 https://www.kernel.org/pub/software/scm/git/docs/git-config.html并向下滚动到core.autocrlf描述：
将此变量设置为“true”与设置text所有文件上的属性为“auto”，core.eol 为“crlf”。设置
true 如果你想拥有CRLF工作中的行尾
目录和存储库具有 LF 行结尾。这个变量可以
被设置为input，在这种情况下不执行输出转换。
换句话说，core.autocrlf=true就像使用auto对所有文件进行设置，这是你永远不应该做的事情。所以你永远不应该使用这个。 ：-） 它can工作，但我不推荐它：创建一个适当的.gitattributes并在那里列出您的所有文件，这样您就不会玩猜谜游戏。一旦你的.gitattributes文件列出了所有内容，core.autocrlf=true没有影响，因为.gitattributes设置会覆盖它。
Using core.autocrlf=input告诉 Git 做同样的猜测，但也只做输入转换（在此期间git add例如清洁）。我自己对这种设置没有任何用处，并且无法真正想象在任何情况下这是一个好主意。这种情况可能存在，但如果您确实要进行转换，则应该明确指定它们；一旦您在您的中正确指定了它们.gitattributes文件，似乎在两个方向上进行转换更有意义，所以没有理由使用input.
至于设定core.eol to native，文档声称这是默认设置（并且似乎是最佳选择），因此除了覆盖其他配置文件对非默认设置的不良选择之外，没有理由打扰。
