雲 Mac 上 Git 大倉「慢」與「爆盤」的五種工程簽名
雲租裸金屬的優勢在於獨佔 NVMe 與統一記憶體頻寬，但 Git 的物件資料庫在預設全量克隆下仍會線性吃滿磁碟，而 git index-pack 與大量小檔案寫入會把單核 CPU 與隨機寫放大推到肉眼可見的尾延遲。2026 年在亞太或北美之間切換節點只能改變 RTT 與跨區頻寬賬單，無法改變「歷史物件體積」與「工作樹展開面積」這兩個硬約束；因此第一步永遠是把症狀歸類，而不是先爭論「是不是該換美西」。
下面五條簽名對應五類根因組合：當你能在工單系統裡穩定貼上其中任意兩條標籤，就應該同步更新容量與拉取策略的決策記錄，而不是讓同事反覆嘗試「再 clone 一次試試」。若你們已經在評估 Xcode Cloud 與裸金屬構建機的分流，可把站內《Xcode Cloud 還是裸金屬雲 Mac》當作並行閱讀；本篇把鏡頭對準 .git 目錄增長、物件獲取策略與磁碟水位 三者的耦合。
物件下載長時間卡在百分之九十九但磁碟幾乎不漲：典型是遠端限速、TLS 中間裝置或跨區小包 RTT 抖動，而不是本地 unpack 慢。
磁碟每分鐘穩定上漲但 CPU 單核打滿、網路並不滿：典型是大倉全量歷史在本地展開，或 LFS 指標檔批次替換為實體檔案。
clone 完成後互動仍卡、Swap 事件增多：常見是 Xcode 索引與 SwiftPM 解析在同一套 16GB 統一記憶體上與巨型工作樹搶頻寬，需要稀疏檢出或拆 workspace。
同一臺機器上第二份 clone 明顯比第一份更慢：要檢查是否共享同一預設快取路徑導致鎖競爭，或系統盤水位已觸發作業系統級回寫節流。
fetch 偶發極慢且與業務時段相關：更像共享出口或 CI 洪峰擠佔頻寬，而不是 Git 協議本身；需要把「成員到雲 Mac」與「雲 Mac 到遠端」兩段鏈路分開採樣。
識別簽名之後，團隊可以把爭議從體感遷移到「我們缺的是更短的 Git 網路路徑、更小的物件集、還是更大的可寫盤與更嚴格的 sparse 邊界」。這與遠端會話裡的 SSH 抖動不是同一維度的問題；若你同時遇到終端手感與 clone 雙峰，可交叉閱讀站內《遠端會話質量驗收》一文，把鏈路與磁碟拆開量。
mono-repo 在 iOS 與 macOS 團隊裡往往還承擔 Bazel 或 Xcode 多 scheme 的編排職責，意味著一次無約束的 clean 可能觸發跨子樹的大量重編譯，間接放大 .git 與工作樹雙邊的 IO。把「允許檢出哪些子樹」寫進倉庫級政策，比事後要求每個人自覺不跑全量指令碼更有效。
最後提醒：雲 Mac 的 256GB 入門盤在 mono-repo 場景裡並不是「小」，而是要求你把歷史物件與工作樹解耦；256GB 能否扛住取決於你是否願意用 blobless 或 partial clone 把歷史_blob 延遲到真正需要時才取回。若團隊堅持全量歷史且還要本地保留多份 release 分支，磁盤曲線會在第三週開始變陡，這是可預期的數學結果而不是供應商暗限速。
淺克隆、blobless、sparse-checkout 與淺 fetch：誰解決什麼問題
沒有一種引數能同時最大化「歷史完整性」「磁碟佔用」「首次 clone 時間」與「後續 blame 體驗」；工程上只能選主最佳化目標並在表裡寫清副作用。下表刻意用粗粒度列，避免把你們內部合規要求寫死；用途是讓負責人在十分鐘站會內對齊「我們到底缺哪一類槓桿」。
| 策略 | 主要收益 | 主要代價 | 典型適用 |
|---|---|---|---|
| 淺克隆 | 顯著減少歷史深度與物件體積 | blame 與部分合並基線受限 | CI 只關心最新提交 |
| blobless / partial | 工作樹可完整，歷史 blob 按需取回 | 首次檢出後仍可能突發網路取 blob | 互動開發需要完整樹但磁碟緊 |
| sparse-checkout | 工作樹面積驟減，索引壓力下降 | 需要維護錐形路徑與文件紀律 | mono-repo 多應用共存 |
| 淺 fetch | 日常同步更快 | 本地缺失遠端已刪分支的歷史 | 長生命週期 feature 機 |
| LFS 本地快取集中 | 跨 job 複用二進位檔，減少重複拉取 | 需要磁碟預算與清理策略 | 大資源頻繁變體 |
把「全量歷史」當作預設選項，等於預設接受磁碟與單執行緒 unpack 的複利成本。
當你能明確說出「我們缺的是更小的工作樹還是更小的物件資料庫」時，擴容決策就不會被誤導向「先加記憶體試試」這種只解決一半問題的路徑。記憶體加寬只能緩解索引與連結階段的尖峰，無法解決 .git 目錄本身的體積膨脹；反過來，若磁碟長期低於百分之五十而 clone 仍慢，瓶頸更可能在跨區鏈路與遠端吞吐策略。
與「加盤還是加機」的容量維度決策仍可對照站內矩陣文章：本篇補的是在固定盤寬下如何把 Git 物件曲線壓平，兩者合併才構成完整的容量治理閉環。
LFS 指標檔、同區快取與目錄約定：把二進位檔搬運關進籠子
Git LFS 把大檔案從物件資料庫中解耦後，真正的成本轉移到「指標檢出」與「實體檔案快取命中」兩段。若構建機在新加坡而 LFS 儲存桶預設在美西，你會看到 CPU 很閒但任務牆鍾很長，這是典型的跨洋搬運而不是 Git 算力不足。把 LFS 遠端與主要 clone 源放在執行機構建的那臺雲 Mac 所在大區，是降低尾延遲的第一步。
目錄級約定上，建議把 GIT_LFS_SKIP_SMUDGE 與顯式 git lfs pull 的分工寫進 CI 指令碼：開發機可以按需 smudge，CI 則只在需要測試資源時才拉實體，避免每個 job 都把數 GB 資源重複鋪到系統盤。多人共享一臺雲 Mac 時，還要把 LFS 快取路徑從預設家目錄改到可配額子樹，否則會出現「某人一次試跑吃光快取目錄」的隱性爭用。
git clone --filter=blob:none <REPO_URL> app cd app git sparse-checkout set apps/ios libs/shared git lfs install --local git lfs pull --include="*.psd,*.zip"
上述命令只是形狀示意，真實錐形路徑應以你們 mono-repo 的頂層佈局為準；關鍵是讓「工作樹展開面積」與「LFS 包含模式」在 code review 中可審計，而不是散落在各人的 shell 歷史裡。對帶子模組的組合倉庫，還要額外核對子模組是否也走了 blobless，否則會在子目錄裡悄悄拉回全量歷史。
提示：把磁碟水位檢查寫進每週 cron 或 CI 前置指令碼，比依賴「誰覺得卡了再說」更能透過審計；水位與 sparse 邊界應出現在同一頁 Runbook 上。
六步 Runbook：從首次 clone 到周檢水位凍結
凍結主最佳化目標：在 wiki 寫明本輪優先「磁碟」「首次牆鍾」還是「blame 完整性」，避免三人三種 clone 參數。
取樣兩段鏈路：分別記錄成員到雲 Mac 的 RTT 與雲 Mac 到 Git 遠端的 RTT，並各抓一次大包傳輸曲線。
選擇物件策略：在淺克隆、blobless、全量三者中二選一為主路徑，並在 CI 與開發機之間允許差異但需文件化。
落地 sparse 邊界：由架構組維護錐形路徑列表，變更走 review；禁止個人臨時 sparse-checkout disable 上生產機。
配置 LFS 快取：統一 GIT_LFS_PATH 或等價快取根，配夜間清理與水位告警閾值。
周檢凍結：連續三週記錄 .git 增速、系統盤水位與一次乾淨構建峰值，未過線再寫入月租或季租決策。
三條可寫進水位的工程口徑與六區擺放簡表
系統盤周均線：任意連續五個工作日系統盤高於百分之七十五且 .git 周增速超過團隊基線兩倍，則必須啟動 blobless 或外遷第二工作副本，而不是先討論加記憶體。
Swap 與索引聯防：在 16GB 機型上若白天互動窗口出現可復現的 Swap 風暴且與 Xcode 索引併發強相關，應把稀疏檢出粒度收緊或把 CI 遷到獨立例項。
跨區搬運比：當雲 Mac 到製品 registry 的牆鍾時間長期高於成員到雲 Mac 的十倍，應優先調整大區或啟用同區映象，而不是繼續堆並行 job 數。
注意：上述閾值為工程溝通口徑，不構成對具體雲廠商 SLA 的承諾；跨 ISP 路徑應以你們實測 traceroute 與物件儲存簽名 URL 的 TLS 握手樣本為準。
僅依賴「每個人都用預設 git clone」時，mono-repo 會在第三到四周把 256GB 系統盤推到危險區，團隊只能用反覆刪庫與全量重拉來吸收成本，並把失敗偽裝成「今天網路不好」。相對地，把物件策略、sparse 邊界與 LFS 快取寫進可審計的 Runbook，並在新加坡、日本、韓國、香港、美國東部與美國西部之間用日租或周租先跑樣本，再決定是否月租鎖盤寬，更符合短中期專案的現金流節奏。MESHLAUNCH 的 Mac Mini 雲端租賃通常是更優解：它讓你們可以把 Git 與構建鏈路落在真實裸金屬與真實跨區路徑上，用彈性租期驗證磁碟與頻寬閾值，而不是把風險堆在預設引數與共享出口上。
以執行 clone 與測試的那臺雲 Mac 為主錨點，讓 LFS 與主要製品拉取儘量同區。構建與 Xcode Cloud 分流角度可交叉閱讀 Xcode Cloud 與裸金屬決策。
最忌諱全量歷史加深工作樹再疊加多份並行 clone 與預設 DerivedData。會話與鏈路手感可對照 幫助中心 的遠端接入說明。