Question

我刚注意到，有时在主分支和功能分支之间切换时，即使已经拉动/推动所有东西+最新......

如果我这样做

git checkout featureBranch

它是即时的（没有进度信息）。

但是当我做的时候

git checkout master

需要更长时间，您还可以获得进度信息：

Checking out files: 100% (312/312), done.

即使我只是来回切换几次，这种行为也是可以重复的。

只是好奇 - 导致这个问题的底层实现细节（？）是什么？

Answer 1

更新 - torek指出（在评论中）git在开始显示状态之前耗尽了计时器 - 因此快速结帐根本不会显示状态，但如果它开始需要很长时间你可能会注意到，你可以看到进步。更新了几个单词以反映出来。

在某种程度上，我说这必须与特定的回购有关，因为我不知道任何方式（除了＆＃34;是第一个分支的默认名称＆＃ 34;）git认为master特殊为分支。

但我可以做出有根据的猜测。当有打包对象时，git会优化任何给定文件的最新版本。例如，假设你有

A --- B --- C <--(master)
             \
              D <--(feature)

D中的每个文件都是＆＃34;最新版本＆＃34;该特定文件;所以要么它是一个松散的物体，要么它是一个非差异的物体。包文件中的对象。因此，检查feature并不需要修补任何文件;它只是读取blob。它可以发生得足够快，以至于git并不觉得需要开始显示状态。

理论上C可能有旧的版本＆＃34;一些文件，可以表示为＆＃34;差异来自较新版本的文件＆＃34;一包。在实践中，只有一个较新的提交在您的活动分支中，我怀疑它会发生。但是在一个真实的回购中，master可能落后develop而develop可能落后于任意数量的功能分支，master头部并不太可能commit有一些打包和差异对象要解决。我怀疑补丁的应用是否需要足够的时间来提供可见的状态报告。

这不是唯一可能的解释。也许你在master下有一个更大的工作树，或者LFS的使用可能是一个因素（尽管我认为你在这种情况下会看到不同的输出）。就像我说的那样，我一般都怀疑回购特定的因素在起作用。只是我上面描述的是一个＆＃34; repo-specific因素＆＃34;这可能适用于大多数非平凡的回购。

更新2 - 我的基础声明 - master并不特别 - 非常容易测试。克隆回购，并在克隆

git checkout master
git branch featureOldMasterBranch
git checkout featureBranch
git branch -f master

现在，在master的克隆结帐中，featureOldMasterBranch的结帐应该是即时的，master的结帐应该花费足够的时间来显示可见的进度更新。

记住分支只是一个ref只是一个指针，这表明它对提交有所不同 - 即特定于repo的东西 - 而不是private final static org.apache.log4j.Logger logger = LoggingUtils.getLogger();的任何特殊处理。

为什么＆＃39; checkout master＆＃39;花费的时间超过了结帐功能分支＆＃39;？

1 个答案: