在git pull上将一个文件从LF更新为CR/LF的最简单方法？

关于EOL转换有很多问题，但我找不到这个特殊情况的答案：我在Unix行结尾中有一个readme.txt。此文本文件是存储库的一部分，该存储库部署在用户的机器上，并使用simple

git pull

进行更新

我们意识到该文件应始终处于CR/LF中，因此希望将其从LF中更改（其他文件也可以）。使用更新

.gittributes

readme.txt eol=crlf

仅当存储库被克隆时才起作用。如果我想更新它，我必须这样做

git pull
git rm --cached readme.txt
git reset --hard

---

i、 e.在每个用户的机器上我都做不到的事情。有办法解决这个问题吗？更新readme.txt是否有帮助？

我一点也不清楚为什么您关心每个用户的工作树中出现的内容。在使用Git时，最重要的是每次提交中出现的内容。尽管如此，我们还是要回答这个问题：

更新readme.txt是否有帮助

是的，会的。（这个答案的其余部分都是可选阅读，但可能是个好主意。）

为什么会这样

eol=crlf

属性告诉Git，当文件从索引复制到用户的工作树时，Git应该只找到冻结格式副本中的

\n

-行结尾，并用用户工作树中的

\r\n

行结尾替换它们

这并不是说你所说的是错的，但你所说的也不完全正确。：-）事实上，这是不完整的。要真正理解这一点，需要理解提交、索引和用户的工作树是如何交互的

提交 记住Git最基本的目的——它存在的理由——是存储提交。每次提交都包含每个文件的完整快照。更准确地说，提交包含该提交中每个文件的完整快照。换句话说，这听起来有些多余，但其想法是，这相当于当时存在的那些文件的存档。每个提交都可以有一组完全不同的文件，但这不是我们通常使用Git的方式

您可以天真地从一个归档程序中构建这样一个东西，比如

rar

或

tar

或

zip

或其他任何东西，每次您想要提交时，只需创建一个新的完整归档。每个这样的档案将完全独立于以前的每个档案。这使得他们以后很容易回来。缺点是这些将占用大量空间，并且很容易失去跟踪

我们首先观察到，每次提交都倾向于重用以前归档中的大部分文件。如果我们没有制作一个独立的档案，而是制作了一个尽可能重复使用前一个档案的档案呢？事实上，Git就是这样做的

为了使这项工作更有效、更快，Git又增加了几个技巧。最主要的一点是，每个文件的数据及其内容都存储在压缩的、只读的、Git-only格式中，这使得快速查看Git是否已经有了该文件的副本。因为它是只读的，事实上，每个提交的每个部分都是只读的。基于查找文件内容，重新使用文件的旧副本是非常安全的

我喜欢将这种只读、Git-only、压缩格式称为“冻干”。它清楚地表明，除非您首先将数据恢复为正常的日常格式，“再水化”它，否则您无法实际使用这些数据。（即时文件：只需加水！）

索引和工作树 每个文件的提交副本都存储在数据库中。1当您签出或切换到某个提交时，Git会将文件从数据库中复制出来。这会使它们重新水化，使它们变得有用

Git可以到此为止，有两组实体：提交和工作树。提交是只读的，工作树是完成工作的地方。您将从工作树构建新的提交。其他版本控制系统正是这样做的。。。但Git没有。相反，Git在当前（或

头
）提交和工作树副本之间插入每个文件的第三个副本

这实际上是在中间的第三个副本，在另外两个之间，所以可能是第二个副本是在冻干格式中，但是不像提交中的副本，您可以更改此副本。更准确地说，你可以替换它。这个中间副本存储在Git调用的索引或暂存区域（或者，现在很少是缓存）中。2
索引有多个角色，可能是其多个名称的来源，但其主要角色可以描述为您将在哪里构建下一个提交。因为它开始时与您签出的提交匹配，所以它已经准备好了每个文件，可以进行新的提交。但假设您以某种方式更改了工作树文件。如何改变并不重要，重要的是你改变了它。此工作树文件尚未在索引中

您必须在更新的工作树文件上运行
git add
。这会将文件复制回索引中，对其进行压缩并将其转换为冻干格式。这会将上一个副本从索引中引导出来。现在索引包含更新的文件，并且索引再次准备进入新的提交

运行
git commit
时，git会收集适当的元数据（您的姓名和电子邮件、日志消息、当前提交哈希ID等），并生成索引中文件的最终冻结快照版本。由于这些文件已经是冻结格式，这个过程非常快，尤其是与其他版本控制系统相比，这些系统没有令人讨厌的“索引”

当您通过转到另一个分支或“返回时间”到历史提交来提取不同的提交时，Git必须更新索引以匹配提交，并更新工作树以匹配索引。这意味着它必须将每个文件从索引复制到工作树，并在此过程中重新水化。同样，正如我们刚才看到的，
git add