爲什麼「結帳主人」比「結帳功能分支」花費的時間更長？

Question

我剛剛注意到，主機和功能分支之間切換時有時， 甚至當一切都已經拉/推+跟上時代的...

如果我做

git checkout featureBranch 

它是即時的（並且沒有進展信息）。

但是當我做

git checkout master 

它需要更長的時間，而你也可以得到進度信息：

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

而這種行爲是可重複的，即使我只是來回切換幾次。

只是好奇 - 什麼是導致這種情況的底層實現細節（？）？

Answer 1

更新 - 託雷克指出（在評論）是混帳用完計時器開始顯示狀態之前 - 這麼快檢出不顯示地位可言的，但如果它開始採取足夠長的時間，你可能會注意到，你可以看到進展。更新了幾個詞來反映這一點。

---

在某種程度上，我會說這一定是什麼做的特別回購，因爲我不知道任何方式（比「是第一個分支的默認名稱」等）是混帳認爲master特殊作爲分支去。

但我可以做一個有教養的猜測。當有打包對象時，git會優化任何給定文件的最新版本。例如，假設你有

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

在D每個文件將是「最新版本」特定文件;所以無論是鬆散的對象，還是包文件中的「非差異」對象。因此檢出feature不必修補任何文件;它只是讀取斑點。它可以發生得非常快，git並不覺得需要開始顯示狀態。

理論上C可能有一些文件，這可能「從較新版本的文件中，DIFF」在包被表示爲「舊版本」。在實踐中，只有一個更新的活動分支，我懷疑是否會出現這種情況。但是在一個真正的回購中，master可能位於develop和develop之後可能位於任意數量的功能分支後面，因此master頭提交併非不可能有一些打包和擴散對象要解析。我懷疑修補程序的應用是需要足夠的時間來顯示可見的狀態報告。

這不是唯一的可能的解釋。也許你在master下有更大的工作樹，或者LFS的使用可能是一個因素（儘管我認爲在這種情況下你會看到不同的輸出）。就像我說的那樣，通常我會懷疑特定於回購的因素在起作用。這正是我上面所描述的「回購特定因素」，可能適用於大多數非平凡回購。

---

更新2 - 我在這裏的根本要求 - 即master是不是特別 - 是很容易測試。克隆回購，並在克隆

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

而現在的master克隆收銀臺內應該是即時而featureOldMasterBranch結賬應該採取足夠的時間來證明取得明顯進展更新。

記住一個分支只是一個指針，這表明它對提交有不同的意義 - 也就是特定於回購的 - 而不是對master進行任何特殊處理。