git-sizer

計算 Git 存儲庫的各種大小指標，標記那些可能導致問題的指標。通過x-cmd一鍵安裝，即刻體驗高效工作流程。

Language	go
Homepage	https://github.com/github/git-sizer

容器調用: ^{實驗性功能}

1. 使用 docker 模組自動拉取基礎鏡像，並在首次執行時根據需求重構為一個可直接運行的完整軟件鏡像。
2. 在後續運行中，命令會基於已構建好的鏡像快速啓動容器，實現秒級響應。
3. 所有操作均在容器內部完成，與本地系統完全隔離，無需任何本地依賴，安全、乾淨且不留痕跡。
4. 當因軟件版本或依賴發生變化需重構鏡像時，會充分利用 Docker 鏡像構建的緩存機制，最大限度地複用已下載的依賴與構建成果，大幅縮短重建耗時。

該功能仍在測試中，使用過程中如有問題，歡迎在 X-CMD 社區 留言反饋。

x docker kali git-sizer

xd kal git-sizer

---

x install git-sizer

darwin/brew	brew install git-sizer
debian/apt	sudo apt-get install git-sizer
ubuntu/apt	sudo apt-get install git-sizer
kali/apt	sudo apt-get install git-sizer

git-sizer - Git 倉庫體積診斷工具

Git 倉庫越來越慢？克隆要半小時、git gc 卡住不動、CI 流水線頻繁超時？這些問題往往源於倉庫體積膨脹，但具體是哪個環節出了問題——是大文件、冗餘歷史、還是分支策略不當？git-sizer 是 GitHub 官方出品的倉庫分析工具，用一行命令給你完整的體檢報告。

核心能力：量化指標 + 風險評級

git-sizer 遍歷整個倉庫的 Git 對象資料庫，計算 20+ 項尺寸指標，並用星號（*）標記風險等級。一顆星表示輕微注意，五顆星以上需要處理，感嘆號（!）則代表極度危險。輸出分為四個維度：

維度	説明	典型風險點
Overall repository size	倉庫整體對象統計	總大小超過 5GB 時克隆和 repack 明顯變慢
Biggest objects	單個體積最大的對象	單個 blob 超過幾 MB 會影響 checkout 性能
History structure	歷史結構深度	提交歷史過深或標籤鏈過長
Biggest checkouts	單次檢出的工作目錄規模	目錄或文件數量過多導致工作區膨脹

它能幫你發現哪些問題

1. 倉庫整體過大

Git 倉庫建議控制在 1GB 以下，超過 5GB 後 git clone、git gc、git repack 等操作會明顯變慢。常見誘因包括：

• 提交生成的二進制文件（編譯輸出、JAR、node_modules）
• 直接存儲媒體資源而非使用 Git-LFS
• 提交壓縮歸檔文件（ZIP、tarball），這類文件版本間 diff 效率極低

2. 引用數量爆炸

分支和標籤每次 fetch 都要全量傳輸，即使本地已是最新。如果倉庫有幾萬個引用，同步開銷會顯著增加。建議：

• 定期清理廢棄標籤和分支
• 避免將 remote-tracking 分支推送到共享倉庫
• 用 git notes 替代標籤存儲 CI 結果等輔助信息

3. 對象數量過多

對象數量直接影響歷史遍歷成本，git gc、git log -S 等操作都會變慢。可能原因：

• 倉庫包含過多小文件，考慮合併為較少的大文件
• 單一代碼庫職責過重，考慮拆分為多倉庫

4. 大文件（Blobs）

Git 適合管理小到中等大小的文本文件，偶爾有幾 MB 的文件可以容忍，但不應成為常態。解決方案：

• 媒體資源使用 Git-LFS 管理
• 避免頻繁修改的大文本文件（日誌、資料庫 dump、巨型 XML）

5. 巨型目錄（Trees）

每次文件修改，Git 都要複製該文件路徑上的所有目錄對象。如果單個目錄有幾千個文件，成本很高：

• 避免單目錄超過幾千個條目
• 將大量文件分片到多級子目錄

6. 重複的相同文件

同一提交中，相同文件被複制到多個路徑？這會導致倉庫體積正常，但檢出後工作區暴漲——極端情況就是所謂的 "git bomb"。

7. 其他異常

• 路徑長度超過幾百字符（Java 開發者注意）
• 帶註釋標籤互相指向形成長鏈
• 章魚合併（octopus merge）有幾十個父提交
• 提交信息過長

使用示例

分析當前倉庫（簡潔模式，只顯示有風險的指標）：

cd /path/to/repo
git-sizer

完整輸出所有指標（推薦首次分析使用）：

git-sizer --verbose

只看嚴重問題（30 星以上）：

git-sizer --critical

機器可讀格式（JSON 輸出）：

git-sizer --json

輸出解讀

以 Linux 內核倉庫為例，verbose 輸出的部分關鍵指標：

| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Overall repository size      |           |                                |
| * Commits                    |           |                                |
|   * Count                    |   723 k   | *                              |
|   * Total size               |   525 MiB | **                             |
| * Trees                      |           |                                |
|   * Total tree entries       |   264 M   | *****                          |
| * Blobs                      |           |                                |
|   * Total size               |  55.8 GiB | *****                          |
| Biggest objects              |           |                                |
| * Commits                    |           |                                |
|   * Maximum parents      [2] |    66     | ******                         |
| Biggest checkouts            |           |                                |
| * Number of directories  [6] |  4.38 k   | **                             |
| * Number of files        [9] |  62.3 k   | *                              |

腳標 [1]、[2] 等對應具體對象的 SHA-1，可以用 git cat-file -p <commit>:<path> 查看內容。Linux 倉庫雖然大，但各維度比例合理，Git 仍能正常管理。

再看一個 "git bomb" 倉庫的輸出——這種倉庫故意構造病態的樹結構，讓相同目錄無限重複：

| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Biggest checkouts            |           |                                |
| * Number of directories  [1] |  1.11 G   | !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
| * Number of files        [1] |     ∞     | !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
| * Total size of files    [2] |  83.8 GiB | !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |

整個倉庫不到 20KB，但檢出後會爆炸成十億目錄、百億文件。∞ 表示計數器溢出（32 位上限）。

命令列選項速查

選項	作用
--verbose	輸出所有指標（默認只顯示有風險的項目）
--threshold=<n>	只顯示風險等級 ≥ n 星的指標
--critical	只顯示嚴重問題（等同於 --threshold=30）
--json	輸出 JSON 格式（含精確數值）
--json-version=1|2	選擇 JSON 輸出格式版本
--names=none	不顯示對象腳標（SHA-1 和路徑）
-h	查看完整幫助

使用建議

定期體檢

在 CI 流水線中加入 git-sizer --threshold=3，當倉庫指標超過三星風險時觸發告警，防止問題積累到無法挽回。

大倉庫優化前的基準測試

執行任何瘦身操作（BFG Repo-Cleaner、filter-repo、LFS 遷移）前，先用 git-sizer 記錄基線數據，優化後對比驗證效果。

團隊規範制定

結合 git-sizer 指標制定團隊准入標準，例如：

• 單文件大小不超過 5MB（* 級別）
• 總 blob 體積不超過 1GB（** 級別）
• 單目錄條目不超過 1000（* 級別）

排查性能瓶頸

當 git status、git checkout、git gc 變慢時，用 git-sizer 定位是哪個維度超標：

• Total tree entries 高 → 目錄結構太扁平
• Total size 高 → 有大文件或生成產物
• References count 高 → 分支/標籤管理混亂

與類似工具的區別

工具	定位	適用場景
git-sizer	只讀分析，風險評估	診斷現有倉庫問題、制定優化策略
BFG Repo-Cleaner	重寫歷史，刪除大文件	徹底清除已提交的大文件或敏感數據
git-filter-repo	多功能歷史重寫	更現代的 filter-branch 替代品，功能全面
Git-LFS	大文件託管方案	預防性方案，避免大文件進入 Git 歷史

git-sizer 的定位是"診斷儀"而非"手術刀"——它告訴你哪裏有問題，但不直接修改倉庫。實際清理需要用其他工具配合。

來源: https://github.com/github/git-sizer