我刚刚注意到，有时在主分支和功能分支之间切换时， 即使一切都已经被拉/推+最新......
如果我这样做了
git checkout featureBranch
它是即时的（没有进度信息）。
但是当我这样做时
git checkout master
这需要更长的时间，而且您还会获得进度信息：
Checking out files: 100% (312/312), done.
即使我只是来回切换几次，这种行为也是可重复的。
只是好奇——导致这种情况的底层实现细节（？）是什么？
【问题讨论】：
标签： git git-branch git-checkout
更新 - torek 指出（在 cmets 中）git 在开始显示状态之前会用完一个计时器 - 所以快速结帐根本不会显示状态，但如果它开始花费足够长的时间你可能会注意到，您可以看到进度。更新了几句话以反映这一点。
在某种程度上，我会说这一定与特定的回购有关，因为我不知道 git 认为master 的任何方式（除了“作为第一个分支的默认名称”）像分支一样特别。
但我可以做出有根据的猜测。当有打包对象时，git 会针对任何给定文件的最新版本进行优化。例如，假设你有
A --- B --- C <--(master)
\
D <--(feature)
D 中的每个文件都将是该特定文件的“最新版本”；所以它要么是一个松散的对象，要么是一个包文件中的“非差异”对象。所以签出feature 不需要修补任何文件；它只是读取 blob。它可能发生得足够快，以至于 git 感觉不需要开始显示状态。
理论上C 可能有一些文件的“旧版本”，可以表示为包中的“与 newer-version-of-file 的差异”。实际上，在您的活动分支中只有一个更新的提交，我怀疑它会发生这种情况。但在真正的仓库中，master 可能在 develop 后面，develop 可能在任意数量的功能分支后面，master 头部提交不太可能有一些打包和差异化的对象需要解决。我怀疑补丁的应用需要足够的时间才能给出可见的状态报告。
这不是唯一的可能解释。也许你在master 下有一个更大的工作树，或者 LFS 的使用可能是一个因素（尽管我认为在这种情况下你会看到不同的输出）。就像我说的那样，通常我会怀疑回购特定因素在起作用。只是我上面描述的是一个“特定于 repo 的因素”，可能适用于大多数非平凡的 repos。
更新 2 - 我在这里的基本主张 - master 并不特殊 - 很容易测试。克隆 repo，并在克隆中
git checkout master
git branch featureOldMasterBranch
git checkout featureBranch
git branch -f master
现在，master 的克隆结帐应该是即时的，而featureOldMasterBranch 的结帐应该需要足够的时间才能显示可见的进度更新。
记住分支只是一个 ref 只是一个指针，这表明提交是不同的——即特定于 repo 的东西——而不是对 master 的任何特殊处理。
【讨论】：