題干與適用場景
一個包含數百萬檔案和多年歷史的單體儲存庫讓新成員首次複製需要數小時。你會如何選擇 partial clone、sparse-checkout、shallow clone，或它們的組合？
這是面向軟體工程師、建置工程師與開發基礎設施職位的通用技術題。儲存庫規模是約束，不代表真實專案數字。回答要區分物件下載、工作樹範圍、歷史深度、線上依賴與 CI 生命週期。
面試官考察點
強回答會先問團隊需要什麼：完整歷史、單一目錄、離線開發，還是一次性建置。面試官希望聽到 blob:none 的按需取回、tree:0 的更激進取捨、sparse-checkout 對工作樹與索引的影響，以及 shallow clone 不能取代 partial clone 的原因。
回答前需要澄清的問題
- 開發者需要跨目錄搜尋、
git blame與歷史 bisect，還是只建置一個服務？ - 工作是否必須離線，還是可以穩定存取 promisor remote？
- CI 是長期重用工作區，還是每次建置後刪除？
- 儲存庫慢在哪裡：歷史 blob、目前樹、工作樹檔案數，還是建置依賴？
- 是否使用子模組、生成檔或外部工具，它們能否處理缺少的物件？
- 伺服器是否支援 filter，網路、憑證與快取策略是否穩定？
30 秒回答框架
「我會先把問題拆成物件下載、取出範圍與歷史深度。需要完整歷史但不想下載舊檔案內容時，用 --filter=blob:none；一次性 CI 且仍需提交歷史時，可評估 tree:0。只需要少數目錄時，再疊加 cone-mode sparse-checkout；只保留近期提交才考慮 shallow clone。部分複製依賴線上按需取回，所以我會用真實指令、離線演練、首次 checkout、merge 和建置指標驗證，而不是只看複製時間。」
分步驟深入解答
第一步：定位瓶頸
分別測量 clone 傳輸、物件儲存、checkout 檔案數、git status、建置依賴與首次按需取回。Git 的 partial clone 文件指出，完整儲存庫會下載 commits、trees 與 blobs；大型儲存庫中歷史二進位檔與不相關目錄往往是主要負擔。沒有分層測量，就無法判斷應減少哪一類物件。
第二步：選擇物件過濾
--filter=blob:none 保留 commits 與 trees，檔案內容在需要時下載，適合長期開發與多次建置。--filter=tree:0 連 trees 也延遲，初始更輕，適合一次性建置後刪除工作區，但後續遍歷目錄會產生更多按需請求。GitHub 文件也提醒伺服器可以拒絕 filter 並退回完整複製，部署前要驗證遠端能力。
第三步：選擇工作樹範圍
如果開發者只維護 services/payments，可在既有 clone 上啟用 cone-mode sparse-checkout，只讓相關目錄進入工作樹。它不等於刪除歷史物件；切換分支、merge 或衝突處理可能暫時取回或實體化其他路徑。sparse-index 可降低索引規模，但官方文件標記其與外部工具相容性仍需驗證。
第四步：處理歷史與離線邊界
Shallow clone 用 --depth 限制提交歷史，適合不需要舊提交的短生命週期 CI；它會削弱 bisect、merge-base 與歷史稽核，不能解決目前樹或大 blob 的問題。部分複製則要求 promisor remote 可用，離線前應預取目標物件。把開發者、長期 CI、一次性 CI 分成不同範本，並記錄缺少物件的取回、checkout、建置與失敗率。
高品質示範回答
「我先不把所有慢都歸因於歷史。測量初始 pack 大小、checkout 檔案數、工作樹占用、status 與建置時間。如果開發者需要多年歷史，但只在一個服務目錄工作，我會採用 blobless partial clone，再啟用 cone-mode sparse-checkout；這樣減少舊檔案內容和工作樹範圍，但保留提交關係。
對於一次性 CI，如果必須讀取提交歷史而建置工作區很短命，我會評估 treeless clone；如果 CI 完全不需要舊歷史，才使用 shallow clone。三者解決的維度不同，不能用 --depth 取代物件過濾。
我會在目標 Git 服務上驗證 filter 是否生效，測試首次 checkout、跨分支、merge、blame、建置和斷網行為。部分複製依賴線上 promisor remote，離線開發者要先預取或使用完整複製。最後按開發者、長期 CI 和一次性 CI 提供範本，用 clone 時間、按需請求量、失敗率、磁碟占用和建置耗時決定是否推廣。」
常見錯誤
- 只加
--depth=1→ 只減少歷史提交，目前大 blob 仍可能存在 → 按物件類型選擇 filter。 - 把 partial clone 當離線方案 → 缺少物件需要 promisor remote → 做斷網演練並預取或改用完整複製。
- 把 sparse-checkout 當刪除歷史 → 工作樹變小但物件庫仍可能很大 → 分別測量工作樹與物件儲存。
- 所有環境都用
tree:0→ 目錄遍歷和 merge 會產生更多按需請求 → 僅給短生命週期 CI 使用。 - 忽略伺服器能力 → filter 可能被拒絕並退回完整複製 → 在目標遠端驗證協商結果。
- 盲目啟用 sparse-index → 外部工具可能不相容 → 先做工具鏈回歸並保留退出路徑。
- 只看首次 clone 時間 → 後續 checkout 和建置可能變慢 → 記錄完整工作流指標。
追問及應對
追問一：開發者經常需要跨目錄搜尋，sparse-checkout 還合適嗎？
先擴大工作樹或提供按需切換腳本。若跨目錄讀取頻繁，稀疏收益會被反覆取回抵銷，可保留 blobless clone，放棄過窄的 sparse 規則。
追問二：CI 每次都從零開始且只建置一個目錄，怎麼選？
優先評估 treeless partial clone 加快取；若歷史不需要，shallow clone 可能更簡單。用 checkout、建置和快取命中資料驗證，而不是憑術語決定。
追問三：伺服器拒絕 filter 怎麼辦？
把拒絕視為能力約束，不能假設客戶端能強制過濾。升級伺服器、改用受支援的過濾器，或採用鏡像、快取和目錄拆分；同時保留完整複製的安全回退。
追問四：如何為必須離線的開發者設計？
提前確定工作流程所需提交、樹與 blob，執行預取並用斷網測試驗證。若依賴集合無法穩定列舉，完整複製或預打包工作區比執行時按需取回更可靠。