为什么git checkout --detach慢？

Question

git checkout --detach必须做吗？有时，当我在我们的大型代码库上运行它时，它运行5秒钟，有时运行超过一分钟。我不确定影响时差的因素。但是，实际上需要花费时间的是什么？

Answer 1

正如the git checkout documentation所说，有点倾斜：

  

你可以省略＆lt; branch＆gt;，在这种情况下命令退化为    ＆＃34;检查当前的分支＆＃34;，这是一个美化的无操作与    相当昂贵的副作用，只显示跟踪    当前分支的信息（如果存在）。

在您的特定情况下，由于--detach，它毕竟不是无操作，但它仍然可以做出相当昂贵的副作用＆＃34;一部分。

在内部，Git正在遍历当前提交和新提交（它假设这些不同;在这种情况下，这种假设是无害的）。只要这些提交的树不同，就必须对索引和工作树文件进行更改。在某些情况下不允许进行此更改，这将中止git checkout并保持所有内容不受影响。有关详细信息，请参阅Checkout another branch when there are uncommitted changes on the current branch，但请注意，由于树匹配（因为提交匹配），所以＆＃34;树木不同＆＃34; case总是假的：它们总是匹配。

尽管树匹配，但它仍会比较索引和工作树文件，以便报告git status - 就像输出一样。所以你得到两个延迟。一种是通读两组树并将它们与索引内容进行比较（这可能非常快）。第二个是运行git status。这可能是缓慢的部分，特别是如果您的git status有时会更新文件的缓存信息，和/或如果您使用的是Git-LFS。如果您启用了CRLF转换，或者在使用Git-LFS时，在某些情况下Git（或LFS）必须进行大量数据转换并检查以发现一切都是最新的。