Git 儲存庫複製大小估算
輸入
| 工作目錄大小 | 100 MB |
|---|---|
| 提交數量 | 1,000 |
| 每次提交的平均差異量 | 50 KB |
| 封包壓縮率 | 30 % |
Git 儲存庫複製大小估算
依據工作目錄大小、提交數量、每次提交的平均差異量及封包壓縮率,估算 git clone 所需下載的完整大小。
輸入
儲存庫參數
du -sh 在工作目錄根路徑量測。git rev-list --count HEAD 取得精確值。結果
輸入數值即可顯示計算結果。
大小估算
git clone 時實際傳輸的資料量。
Git 儲存庫複製大小
git 儲存庫的磁碟佔用量與執行 git clone 時實際傳輸的資料量,兩者並不相同,也不一定和工作目錄的大小成正比。了解封包歷史的形成方式,有助於在規劃複製策略、清理舊分支及評估儲存需求時做出具體判斷。
封包檔模型
git 並不會在每次提交時儲存所有檔案的完整快照。它把物件(blob、tree、commit)壓縮進封包檔,並在過程中套用兩層壓縮:
- 差異編碼(delta encoding): git 識別相似物件,只儲存相對於某個基底版本的差異,而非完整內容。
- zlib 壓縮: 差異資料再以 deflate 演算法壓縮,與 ZIP 格式相同。
歷史資料估算大小的計算公式為:
其中 為提交數量, 為每筆提交壓縮前的平均差異量, 為封包壓縮率(差異資料壓縮後的留存比例)。
完整複製大小則為:
是工作目錄在 HEAD 的大小,不含 .git 目錄本身。
各參數說明
工作目錄大小()。 目前版本所有已追蹤檔案的總大小。可在儲存庫根目錄執行 du -sh --exclude=.git . 取得,或使用 git-sizer 工具進行詳細分析。
提交數量()。 歷史中的提交總筆數,執行以下指令取得精確值:
git rev-list --count HEAD
每次提交的平均差異量()。 單筆提交新增或修改的原始資料量(壓縮前)。以文字程式碼為主的儲存庫通常在 10–100 kB;包含圖片、執行檔或大型模型的儲存庫,每筆提交可能超過 1 MB,並顯著增加歷史體積。
封包壓縮率()。 原始差異資料壓縮後的留存比例,以小數表示。純程式碼儲存庫通常可達 20–40%,意即封包檔只需原始差異資料的五分之一至五分之二空間;PNG、MP4、已壓縮的二進位資產則幾乎無法再壓縮,壓縮率接近 80–100%。
計算範例
以下列條件的儲存庫為例:
- 工作目錄:100 MB
- 提交數量:5,000 筆
- 每次提交的平均差異量:80 kB
- 封包壓縮率:30%
歷史資料估算大小:
完整複製大小估算:
.git 目錄何時會大於工作目錄
新建立的儲存庫通常只有少量提交,.git 目錄遠小於工作目錄。隨著專案累積歷史,特別是多位貢獻者長期頻繁修改相同檔案時,封包歷史可能大幅超出最新快照的體積。超過 10,000 筆提交、且大量改動的儲存庫,歷史資料佔用兩至三倍工作目錄大小的情況相當常見。
加速歷史增長的常見因素:
- 二進位檔案(圖片、執行檔、套件)的不同版本之間差異巨大,難以有效編碼
- 大型文字檔每次整頁覆寫,而非局部修改
- 長期存活的分支在合併後未清理
淺複製與部分複製
git 提供多種機制,讓不需要完整歷史的場景可以減少傳輸量。
淺複製(git clone --depth N): 只下載最近 筆提交。對含有 10,000 筆提交的儲存庫使用 --depth 1,只會傳輸最新快照加上薄薄一層元資料,傳輸量約等於工作目錄大小。對歷史較深的儲存庫而言,複製流量可減少 90% 以上。若後續需要補充歷史,可執行:
git fetch --unshallow
部分複製(git clone --filter=blob:none): 下載完整的提交與樹物件中繼資料,但延遲取得 blob 內容,直到實際需要時才索取。適用於持續整合環境,既需要完整的提交歷史,又不需要立即取得所有檔案內容。
git sparse-checkout: 只簽出工作目錄的特定子目錄,在不影響歷史完整性的前提下縮小磁碟佔用。
查詢實際大小的工具
估算值適合規劃與評估,若需要磁碟上的確切數字,可使用以下指令:
# 物件狀態摘要(含封包檔)
git count-objects -vH
# 列出最大的前 20 個物件
git rev-list --objects --all \
| git cat-file --batch-check='%(objectsize:disk) %(rest)' \
| sort -rn \
| head -20
git-sizer 工具可提供更完整的結構化分析,包含工作目錄、歷史資料及體積最大的 blob 清單,是規劃儲存庫維護策略時最可靠的參考來源。
相關計算
若要估算二進位資產的壓縮效果,請參考 壓縮率計算機。若要計算複製或推送所需的傳輸時間,請參考 資料傳輸時間計算機。若要評估 Base64 編碼對 git LFS 指標或 CI 快取的空間影響,請參考 Base64 編碼開銷計算機。
常見問題(FAQ)
為什麼 .git 目錄有時比工作目錄還大?
git 以物件形式儲存每個檔案的每個歷史版本。一個曾被修改 200 次的檔案,在物件資料庫中就有 200 筆記錄。隨著時間推移——尤其是歷史悠久、貢獻者眾多的儲存庫——累積的歷史資料可能遠超出最新快照的大小。git 的封包壓縮雖可縮小歷史體積,但除非刪除舊分支或改用淺複製,否則歷史與工作目錄的大小比例通常只會持續增加。
淺複製如何減少下載量?
淺複製(git clone --depth N)只下載最近 N 筆提交的歷史,其餘保留在伺服器端。以一個有 10,000 筆提交的儲存庫為例,--depth 1 只會下載最新快照,大小約等於工作目錄加上薄薄一層物件資料——對較舊的儲存庫而言,複製流量可減少 90% 以上,代價是本地端無法取得完整歷史。若後續需要補充歷史,可執行 git fetch --unshallow 將淺複製逐步加深。
免責聲明
此結果為基於簡化封包模型的啟發式估算值。實際儲存庫大小取決於物件類型、差異鏈深度、重新封包設定及 git 版本等因素。執行 git count-objects -vH 可取得磁碟上的實際大小。