我在一个团队中工作，除了我以外的所有人都在使用Mac。我正在使用Windows 10。 当我们意识到CRLF存在问题时，我克隆了远程团队存储库并使用它。 我更改了一个git选项，但现在我想再次更新repo但没有检测到它的变化，所以我不知道如何在所有存储库文件中使用与正确行结尾相同的文本。
提前谢谢。
答案 0 :(得分：0)
答案是，从字面上看，删除所有文件，然后再次检查出来：
git rm -r -- . # remove everything
git checkout HEAD -- . # check everything out again
（旁注：此处的示例使用--，名称.不需要{只有当文件名看起来像分支名称或一个命令选项。一直习惯使用它是一个好习惯，所以如果你想稍后查看一个名为master的文件，你只需要自动写git checkout -- master并且不要## 39; t意外地写了git checkout master，这显然做了不同的事情。）
这里有一个相当基本的Git烦恼，就是Git试图提高效率。使用稍短的命令git checkout -- .，否则会完成您想要的操作，但Git将您的索引/登台区/缓存 1 中的内容与“＆lt;”进行比较。在你的工作树里。 Git使用＆＃34;缓存＆＃34;通过知道索引正在索引/缓存工作树内容以便在索引和工作树中没有任何更改的情况下，索引的一个方面可以加快这一点，因此每个文件的工作树版本会自动生成正确匹配同一文件的索引版本。
索引的简短描述是您构建下一个提交的位置。这就是为什么它的名称暂存区域：你＆＃34; stage＆＃34;将文件放入其中，当您进行提交时，新提交将使用此阶段中的任何内容来创建快照。它基本上永远不会为空（除了我们上面的git rm -r -- .之后！）：它开始持有当前提交中的每个文件。稍后，您将使用git add 将文件的索引版本替换为较新版本。
Git主要是关于提交，每个提交存储每个文件的完整快照 - 自上一版本以来没有更改，只是整个文件，完整但压缩。提交中的副本采用此特殊压缩Git格式，并且只读，因为它们永远不会被更改。索引中的副本最初只是提交中副本的可替换版本，仅使用几十个字节存储，因为它确实 提交中的版本，直到用新版本覆盖索引副本。因此索引副本也是特殊的Gitty格式，对大多数程序都没用，只适用于Git本身。
因此，您工作的内容是 work-tree 中的文件，因为它是目录树（具有子目录的目录或文件夹）而命名或者你执行工作的子文件夹，所有这些文件都包含文件。 Git将提交中的文件提取到索引中，以便可以替换它们，然后将索引中的文件提取到工作树中，以便将它们扩展为有用的格式。
这里有一个棘手的部分：当文件从索引转到工作树，或从工作树转到索引时，所有特殊的行处理都会发生。所以{ {1}}，它从索引中提取一个文件到工作树，在创建您将使用的文件时重新执行行尾处理。在将文件压缩为特殊的仅Git格式以将其填充到索引中时，最终的git checkout -- <file>将撤消任何特殊的行结束处理。
但如上所述， Git试图提高效率。索引不仅包含文件的副本，还包含关于文件的信息，以便快速帮助Git弄清楚索引中的副本和工作树中的副本之间是否存在任何差异。如果Git只是签出该文件，Git 知道某些工作树中的副本匹配索引中的副本。< / p>
如果更改了行尾处理，则更改方式 Git会将索引中的文件提取到工作树中。这意味着工作树中的副本不再有效。这就是烦恼的来源： Git并没有意识到工作树副本不再有效。它认为它仍然是一个完美的匹配，并且不会再次提取文件以避免浪费时间。
这浪费了你的时间，因为现在你必须做某事（比如删除文件）只是为了让Git做某事（重新提取文件）。 git add -- <file>从当前目录/文件夹（git rm -r -- .）中的工作树和索引中删除每个文件，然后.将当前提交中的每个此类文件重新提取到索引中，然后再提取到工作树中。这遵循新的行尾设置，并以您想要的形式获取文件。
您只需在最初设置Git时更改行尾设置时执行此操作。所以这是一种一次性的交易 - 它并不像这种描述那样痛苦。但我认为 是一个错误。
1 这是三个不同的名称，它们反映了它的重要性（ 非常重要），或者它的多个不同的角色（它有几个角色） ，或者是因为使用的名字＆＃34;索引＆＃34;，是一个如此糟糕的名字。 ： - ）