如何在所有克隆/机器上禁用Git的行尾(CRLF转换为LF)？

Question

正如人们可以从其他文章中了解到的，Git的行末标准化有其优缺点。我有一个特定的仅限Windows的项目，在这个项目中我认为最好的做法是完全禁用行末标准化。也就是说，我想保留所有换行符（其中大多数是CRLF），而不是让git在后台将它们规范化为只有LF，并且我希望这个更改影响所有机器上克隆的存储库。问题是最有效的方法是什么。

关于Git行末标准化的大多数讨论都是基于core.autocrlf，我可以通过设置core.autocrlf=false来实现我的目标。然而，这是一个git-config设置，我相信每台机器都必须单独设置。如果是真的，那么这似乎很容易出错，特别是因为msysgit安装程序会引导用户将core.autocrlf=true设置为默认值。

- Chris

Answer 1

避免在每台机器上单独设置core.autocrlf的最佳方法似乎是将一个包含单行的.gitattributes文件检入存储库。

* -text

或者，如果您使用的是旧版本的 Git，则

* -crlf

这段文字告诉Git，在所有路径中（因此使用了*通配符），不应尝试进行行末标准化。据我所知，这不应该产生其他任何副作用。特别是，它不应更改生成差异的方式（这有单独的属性diff/-diff）或处理合并的方式（这有单独的属性merge/-merge）。

如需更多详细信息，请参阅以下资源：

1. gitattributes文档（git help attributes或在线版本），详细描述了行尾规范化的工作原理以及不同属性的特定影响。（可能最相关的是text，crlf，diff，merge和binary。）
2. Git邮件列表线程“text”属性是否仅用于指定行尾规范化行为，还是具有更广泛的含义？（2012年3月30日），扩展了不同属性的含义，并澄清了-text并不意味着“这是一个二进制文件”。

- Chris

---

你发的链接已经失效了，也许你可以用这个链接代替？http://git.661346.n2.nabble.com/Is-the-quot-text-quot-attribute-meant-only-to-specify-end-of-line-normalization-behavior-or-does-it--td7420001.html - Antimony

使用 core.autocrlf=true（默认值），Git 在检出时不会修改行尾吗？这是在它甚至读取 .gitattributes 之前发生的事情吗？（.gitattributes 本身将具有 CRLF）。然后，在提交时，Git 被告知不要转换 CRLF（-text），因此您最终在存储库中得到的是 CRLF。 - Michel Jung

@git可以在从远程仓库拉取代码之后，但在检出文件之前，从本地仓库读取.gitattributes。本地仓库应该与远程仓库的行尾相匹配。只有在检出并提交文件时才会执行行尾转换。 - Jason