小红帽的灰灰狼某个周一的上午，我正准备把手上开发了一个多月的大功能分支合并回主分支，CI机器突然弹出一条磁盘告警：仓库的.git目录已经膨胀到接近6GB，clone一次完整代码需要5分钟，新同事入职第一天的前两个小时全花在“等代码下载”上。团队群里开始讨论要不要换仓库、要不要做partial clone，我却想先弄清楚一件事：这6GB到底是谁带来的？是哪个分支在“负重前行”？
要回答这个问题，就得学会统计Git各分支的大小。很多人一听就想用du直接看目录，但Git的存储模型决定了分支大小远没有du -sh那么直观。这篇文章就从我当时的排查经历出发，把“怎么统计分支大小、统计结果怎么解读、统计完怎么治理”一次性讲清楚，适合负责仓库维护、做CI/CD优化、或者单纯想搞明白自己功能分支为什么那么大的开发同学。前提很简单：装上Git，能开终端，动手试。
1. 为什么需要关心“分支大小”：从磁盘告警和仓库发胖说起
1.1 仓库一直在变大，但经常没人说得清来源
Git仓库体积膨胀，几乎每个中大型团队都会遇到。默认情况下，Git把所有历史都完整保存在本地.git目录中，一个分支的每一次提交、每一次合并、每一次误操作，都会在对象库里留下永久记录。删除文件从来不会让仓库变小，这个反直觉的事实是很多人第一次面对仓库体积问题时最困惑的地方。
我见过不少团队，仓库从几百MB涨到几个GB，中间毫无感知。等到某天CI拉代码的时间超过了构建时间，或者服务器磁盘告警，才开始着急。但更尴尬的是，这时候往往没人能回答“体积主要是谁贡献的”。
这不是某个人的锅，而是Git的存储模型天然让“按分支归因”变得困难。分支不是文件夹，对象不是按分支打包存放的。后面我会详细拆这个事，但先记住结论：想治理仓库膨胀，第一步永远是先定位大分支、大对象，而不是盲目gc或者重写历史。
1.2 什么场景下必须做分支体积统计
结合我自己踩过的坑和帮别人排查的经验，下面几种场景尤其需要做分支体积统计：
- 磁盘和CI告警：服务器磁盘快满了，CI拉代码从10秒变成2分钟，这时候需要快速找出“元凶分支”。
- 合入前审查：同事提交了一个功能分支，怀疑里面带了模型文件、视频素材、编译产物等大文件，与其在Code Review里争论，不如直接跑统计给数据。
- 分支清理决策：仓库里有几十个旧分支，不知道哪些可以安全删除。如果某个分支独有对象体积巨大，删除它释放的空间会比想象中多得多。
- 仓库迁移或拆分规划：准备做仓库瘦身、模块拆分，或者决定是否要把某个大目录迁到独立仓库，前一步一定是摸清每个分支的内容规模。
很多人觉得统计分支大小是仓库管理员才需要做的事，其实普通开发者也应该掌握。你提交的每一个大文件，都在影响所有协作者的clone和拉取速度。早一点发现问题，就能少一次被迫重写历史的折腾。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 分支大小的本质：Git的对象模型与“共享”陷阱
2.1 分支只是一个指向commit的引用，不是文件夹
要理解分支大小，必须先理解Git最底层的对象模型。Git的核心存储单位是四种对象：blob（文件内容）、tree（目录结构）、commit（快照元数据）、tag（标签）。其中blob按内容寻址，相同内容的文件只会存一份，不管你在多少个分支、多少个历史版本里出现过。
分支是什么呢？它本质上是.git/refs/heads/下一个只有几十字节的文本文件，里面保存着一个40位的SHA-1（或者64位的SHA-256）值，指向某个commit对象。就这么大点东西，不可能“装下”任何真正的文件内容。
所以“分支大小”在Git里从来不是一个现成的属性，它需要被计算：从一个分支指向的commit出发，沿父子关系回溯所能到达的所有对象，这些对象的体积之和，才近似是这个分支“带来的内容量”。 我习惯用档案馆来类比：.git对象库是一整座存放文件底稿的档案馆，分支只是一张写着“请把A-101柜、B-202柜的资料都调出来”的借阅单。单子本身很轻，但它背后关联的资料可能塞满一个房间。
2.2 为什么直接量目录不靠谱
很多人第一次尝试统计分支大小，第一反应是看.git/refs/heads/下文件的大小，或者直接du -sh .git。这两种做法都有问题。
先看du -sh .git/refs/heads/——这里放的分支文件只有几十字节，量出来的结果是几KB甚至4KB（文件系统最小块），完全没有任何参考意义。再看du -sh .git——这个数字是整个仓库对象库的总磁盘占用，它是所有分支、所有历史共同占用的结果，但你无法从这一个数字里拆出某个分支的份额。
根本原因在于，Git把对象打包进packfile时，从来不会按分支隔离存放。一个packfile可能同时包含主分支和十个功能分支的内容，对象之间还做了delta压缩，互相引用。你在文件系统层面做任何目录统计，都不可能还原出分支维度的体积。
2.3 三种“分支大小”口径，各解决不同问题
动手统计之前，先想清楚你想要哪个口径。我平时会区分三种，它们各有用途：
| 口径 | 含义 | 计算方式 | 适合场景 | 局限 |
|---|---|---|---|---|
| A. 可 |