有人可以解释一下设置之间的区别：
core.autocrlf = true
core.eol = native
和
core.autocrlf = input
当我们使用这两种情况时？
答案 0 :(得分：5)
何时[应该]我们使用[这些设置中的任何一个]？
我的偏好是从不。另一方面，我也不在Windows上工作。 :-)但是，如果你仔细阅读下面的所有文字，你会看到，如果我这样做，我仍然会说'＃34;永远不会＆＃34;。 （即使您正在共享一些您不允许创建.gitattributes文件的上游存储库，您也可以在自己的克隆中使用每个存储库$GIT_DIR/info/attributes文件。）
[有什么区别？]
为了达到差异，我们首先需要注意：
第一部分非常简单，虽然它为新手提出了自己的绊脚石。 Git可以执行您想要的任何转换，因为它具有Git所谓的清理过滤器和涂抹过滤器。
clean filter 是你的转换 - 是的，你！ - 可以自己编写，当你使用{{1}将文件从工作树复制到索引时Git将会应用} 或同等学历。也就是说，假设您已将文件签出到工作树中，并对其进行编辑，或者将其完全替换，或者对其进行更改以对其进行更改。您可能想要提交该文件的新版本。因此，您必须运行git add将文件从工作树复制回索引。 （请记住，Git会从索引中的任何内容进行新的提交，而不是来自工作树中的内容。这就是为什么你不得不git add path文件一直存在：Git不会自动从工作树复制到索引。）
每当你运行git add时，Git都会＆＃34;清理＆＃34;在途中的文件。这是输入转换。
相反，您可以编写自己的涂抹过滤器，这是您在Git out （在索引之外）进入您的工作时对文件进行的操作-树）。由于Git中的所有文件（包括准备将其复制到 next 提交中的索引中的文件）都采用一些特殊的，内部的，仅Git格式，因此每个文件必须转换为所有常规计算机程序可以处理的正常格式。每当你将文件提取到工作树时，Git都会＆＃34;涂抹＆＃34; （脏了）文件在出路。这是输出转换。
Git偶尔会进行输入转换，而不会将文件实际复制到索引中：特别是，如果运行git add file，必须将工作树文件与同一文件的索引或提交副本进行比较， 内部存储库已经被清理了＃34;而工作树中的全部＆＃34;污迹＆ ＃34;和＆＃34;脏＆＃34;。它们无法进行比较，直到它们处于相同的状态，因此Git将清理＆＃34;清除＆＃34;在做差异之前的工作树。
Git有两个内置转换。一种是在清理时使用，即当文件从工作树复制到Git（进入索引）时。这个替换CRLF行结尾与仅换行，Linux风格的行结尾。另一种是在涂抹时使用，即从Git复制文件时使用。这个用...取代仅换行的Linux风格的行结尾， 。
这＆＃34;某事＆＃34;是git diff进来的地方。你可以让Git用CRLF替换换行符，如果你在Windows上并且你有程序要求这些行以CRLF结尾，你可能会想要它，但你也是与在Linux上工作的人合作，要求这些行以仅使用LF的换行符结尾。
或者，您可以让Git替换仅使用LF的换行符...除非替换，因为换行符 是换行符＆＃34; LF＆＃34;字符。把它称为替代品有点傻。
您可以让Git根据您的系统选择结尾，以便将core.eol设置为core.eol的一项配置适用于 Linux 和< / em> Windows。
Git有点偷偷摸摸：当它要去＆＃34;替换＆＃34; LF与LF（毕竟它不是替代品）它往往什么都不做 - 甚至不检查任何东西 - 因此更快。看起来你可能永远不会注意到这一点，除了native设置要求Git检查事物。 core.safecrlf这个问题涉及一些猜测，如果您正在进行转换，那么您可能会过度保护并设置safecrlf设置，这样您就不会损坏任何二进制文件文件。
某些文件，例如.gitattributes图片，只是不是文字，永远 in＆＃34; text-ish＆＃34;方法。它们需要使用图像处理代码进行操作，而不是使用文本编辑器或笨拙的工具行Git的内置转换。因此，Git需要一种方法来区分 text 文件，这些文件应该从非文本或二进制文件中应用这些行结束转换。< / p>
如果你不告诉Git哪些文件是哪个，那就必须猜测。 Git使用猜测的方法是 not 来查看.jpg或.jpg扩展名 - 这不会对名为.txt的文件起作用，实例。相反，Git会查看存储在文件中的数据，并根据它是否＆＃34;看起来像是文本＆＃34;或者＆＃34;看起来是二元＆＃34;。
你可以想象，这个猜谜游戏并不完美。它可能对你有用，但如果它没有，你可以而且告诉 Git哪些文件是哪个。您可以通过创建名为README的文件来完成此操作。在.gitattributes中，您可以列出特定文件名，例如.gitattributes，或路径名称模式，例如README和*.txt，因为＆＃34;肯定是文字＆＃34;或者＆＃34;绝对是二元＆＃34;。您可以使用*.jpg或text执行此操作。您也可以告诉Git： guess！您使用-text执行此操作：
auto 如果可以提供帮助，则不应使用*.txt text
*.jpg -text
guess auto
。
如果您从未让Git进行任何转换，则不必执行此操作。 告诉Git哪些文件是文本，哪些文件是二进制文件确保Git正确完成转换，如果您正在进行转换，则只需执行此操作。因此，如果您避开Windows，则无需创建auto并列出您的文件。无论如何创建它并没有什么坏处，但是如果你创建它，你应该尝试让它覆盖你的所有文件，这样Git就不用猜了。
考虑到上述情况，我们可以通过咨询the git config documentation并向下滚动到.gitattributes说明来了解core.autocrlf做了什么：
将此变量设置为＆＃34; true＆＃34;与设置
core.autocrlf相同 属性为＆＃34; auto＆＃34;在所有文件和core.eol到＆＃34; crlf＆＃34;。调成 如果您想在工作中获得text行结尾，则为true 目录和存储库具有LF行结尾。这个变量可以 设置为输入，在这种情况下不执行输出转换。
换句话说，CRLF就像在所有文件上使用core.autocrlf=true设置一样，这是你永远不应该做的事情。所以你永远不应该使用它。 :-)它可以工作，但我不推荐它：创建一个合适的auto并在那里列出你的所有文件，这样你就不会玩猜谜游戏。 在您的.gitattributes文件列出所有内容后，.gitattributes无效，因为core.autocrlf=true设置会覆盖它。
使用.gitattributes告诉Git做同样的猜测，但也只做输入转换（例如在core.autocrlf=input清理期间）。我自己没有使用这个设置，并且无法想象它是一个好主意的任何情况。这种情况可能存在，但如果您要进行转换，则应明确指定;一旦您在git add文件中正确指定了它们，在两个方向进行转换似乎更有意义，因此没有理由使用.gitattributes。
至于将input设置为core.eol，文档声称这是默认设置（并且它似乎是最佳选择），因此除了覆盖其他人之外没有理由打扰配置文件选择非默认设置。
答案 1 :(得分：0)
Github文档和git https://git-scm.com/book都推荐以下设置：
git config --global core.autocrlf input git config --global core.autocrlf true 请参阅：
我在混合环境中使用这些设置已有10多年了，从来没有问题。