Git分支大小统计实战：从磁盘告警到仓库瘦身

某个周一的上午，我正准备把手上开发了一个多月的大功能分支合并回主分支，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和拉取速度。早一点发现问题，就能少一次被迫重写历史的折腾。

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给全分支排个序，定位可疑目标；再用口径B验证这个分支是不是“真的多占了”空间；如果需要评估部署/CI的工作目录占用，才会切到口径C。三者结合，才是一个完整的体检报告。

3. 手把手统计：从全局到单分支的实用命令

3.1 先给仓库做个体检：git count-objects 和 du

正式按分支统计之前，我习惯先跑两个命令给仓库做个体检，心里有个底数。

第一个是git count-objects -vH，看对象库的组成：

bash复制git count-objects -vH

输出大概长这样：

text复制count: 156
size: 12.31 MiB
in-pack: 48218
packs: 1
size-pack: 1.52 GiB
prune-packable: 0
garbage: 0
size-garbage: 0

各字段的含义我用一张表解释清楚：

第二个是直接量目录：

bash复制du -sh .git

du的结果就是当前这个仓库在磁盘上的真实占用，包含所有分支、所有历史、所有packfile。如果你发现size-pack已经好几个GB，而全团队实际源码只有一两百MB，那几乎可以肯定有大型对象混进了历史里。

3.2 单分支blob总量快查：一条命令算出来

全局体检只能告诉我们仓库整体多大，接下来要按分支拆。我经常用的核心命令是这样的：

bash复制git rev-list --objects <branch> | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize)' | \
  awk '$1 == "blob" {sum += $3} END {printf "%.2f MiB\n", sum / 1024 / 1024}'

拆开解释一下：

• git rev-list --objects <branch>：从该分支所在commit出发，列出所有可达对象的SHA和路径。注意它不只看最新快照，而是把整个分支历史里出现过的所有对象都列出来。这正是我们想要的“历史总账”。
• git cat-file --batch-check：从标准输入批量读取对象SHA，高性价比地输出对象类型和大小。相比一个个跑git cat-file -s，批量方式在大仓库上快得多。
• awk '$1=="blob"'：只累加blob对象的大小。之所以要过滤，是因为commit和tree对象体积很小，统计它们会干扰判断；真正占空间的是文件内容，也就是blob。

这条命令重复跑，就能得到每个分支的原始内容总量。注意，这个数值是所有历史版本里出现过的blob原始大小之和，没有去重，所以它一定比当前工作树大得多，尤其是一个文件被反复修改过几十次的情况下。

3.3 找出分支里的Top大文件：定位元凶

光知道总量还不够，你得知道是哪些文件在占空间。下面这条命令可以列出指定分支历史中出现过的最大的20个blob对象：

bash复制git rev-list --objects <branch> | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  awk '$1 == "blob" {print $3, $2, $4}' | \
  sort -rn | head -20

输出大致是：

text复制104857600 8f2d1a3e... model_weights.bin
52428800  7c9b34d2... dataset.zip
...

这些数字往往能让你一眼看出问题。根据我这几年帮人排查的经验，出现在“大文件Top榜”里的高频元凶包括：训练好的模型权重（.h5、.pt、.bin）、视频素材（.mp4、.mov）、安装包（.zip、.exe、.dmg）、前端构建产物（dist目录被提交）、以及五花八门的日志文件。这条命令是各种统计脚本里出镜率最高的一条，建议直接存成shell函数。

3.4 相对基线的独有增量：算清楚“这个分支到底多占了多少”

全局总量能排序，但一个分支总量大，不代表它“造成”了那么多独占空间。比如从主分支拉出来的功能分支，天然携带主分支的全部历史，这部分不能说成是功能分支的额外负担。更准确的“归因”方法是：拿该分支可达的所有blob集合，和基线分支（通常是main或master）的可达blob集合做差集，差集部分才是这个分支真正“多出来”的内容。

bash复制git rev-list --objects <branch> | awk '{print $1}' | sort -u > /tmp/branch_blobs.txt
git rev-list --objects <baseline> | awk '{print $1}' | sort -u > /tmp/base_blobs.txt
comm -23 /tmp/branch_blobs.txt /tmp/base_blobs.txt | \
  while read -r sha; do git cat-file -s "$sha"; done | \
  awk '{sum += $1} END {printf "%.2f MiB\n", sum / 1024 / 1024}'

comm -23的含义是：列出第一个文件中存在、但第二个文件中不存在的行。也就是分支里有、基线里没有的对象SHA。再把这些SHA逐个查大小并累加，就得到了分支的独立新增体积。

需要提醒的是，基线选择会影响结果。如果你选main做基线，功能分支还没合并回去，那么功能分支上的所有提交都算“新增”。如果基线是那个功能分支刚拉出来的commit，那新增量就是它后来的改动。更严谨的做法是用git merge-base <branch> <baseline>找到共同祖先，再用这个祖先commit作为比较基准，这样能排除基线分支后续改动的影响。不过日常排查中，直接用main做基线就够了，方向不会错。

3.5 大仓库的加速技巧

仓库很大时，上面的命令可能会跑得比较慢。工程上常用的加速手段有几种：

• 优先使用--batch-check，避免逐个启动git cat-file子进程。我在一个4GB左右的仓库上实测，batch方式和循环调用单个cat-file -s相比，耗时能少一个数量级。
• 用sort -u先做一次去重。因为同一个blob可能被多个commit引用，不去重会导致重复累加，既慢又错。
• 如果只需要判断“某个分支是否引入了大文件”，不要统计完整历史，直接看最新提交和工作树的diff类信息，速度会快很多。

另外一点实战教训：统计过程中尽量避免同时执行gc、repack等写操作。虽然统计本身是只读的，但遇到正在变动的对象库，结果可能不一致，严重的还会报错。如果仓库是团队共用的，最好挑一个没有push的时间窗口来跑。

4. 更专业的工具与自动化脚本

4.1 git-sizer：仓库结构的“体检仪”

单条命令适合快速验证，但做全面体检时，我强烈建议用git-sizer。这是GitHub官方出品的专业仓库体积分析工具，能一次性扫描出仓库里最大的对象、最深的路径、最大的checkout、最宽的树等指标。

安装很简单：

bash复制# macOS
brew install git-sizer

# 或用Go直接装
go install github.com/github/git-sizer/v1@latest

跑一次体检：

bash复制git-sizer --verbose

输出会列出很多“最大项”，有几类信息对分支治理特别有用：

• 最大的blob对象：直接对应历史里的巨型文件。
• 最大的checkout：某个commit对应的目录树展开后有多大，这影响到clone后工作目录的占用。
• 哪些refs引用的大对象最多：能辅助判断大对象主要集中在哪些分支上。

git-sizer的局限性在于它侧重“仓库整体结构”，并不做“分支间共享/独有”的精细拆分。所以我的习惯是：先用git-sizer做整体体检，再用第3节的命令做分支归因，两者配合。

4.2 一个脚本输出全分支的“肥胖排行榜”

单分支命令有了，接下来把它套到所有分支上。下面这个脚本是我日常用得最多的，直接放进branch-size.sh里，加执行权限就能用：

bash复制#!/bin/bash
set -eu

git for-each-ref --format='%(refname:short)' refs/heads/ | while read -r branch; do
  size=$(git rev-list --objects "$branch" 2>/dev/null | \
    git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize)' | \
    awk '$1 == "blob" {sum += $3} END {print sum + 0}')
  echo "$size $branch"
done | sort -n | awk '{printf "%10.2f MiB  %s\n", $1 / 1024 / 1024, $2}'

跑起来的输出是这样的：

text复制   183.42 MiB  main
    96.18 MiB  feature/login
   742.50 MiB  feature/ai-model
    12.05 MiB  fix/typo

一眼就能看出feature/ai-model不对劲。如果你还想看每个分支相对主分支的“独有增量”，把脚本扩展一下，基线作为参数传进来：

bash复制#!/bin/bash
set -eu
base="${1:-main}"
tmpdir=$(mktemp -d)
trap 'rm -rf "$tmpdir"' EXIT

git rev-list --objects "$base" | awk '{print $1}' | sort -u > "$tmpdir/base.txt"

git for-each-ref --format='%(refname:short)' refs/heads/ | while read -r branch; do
  if [ "$branch" = "$base" ]; then
    continue
  fi
  git rev-list --objects "$branch" | awk '{print $1}' | sort -u > "$tmpdir/branch.txt"
  size=$(comm -23 "$tmpdir/branch.txt" "$tmpdir/base.txt" | \
    while read -r sha; do git cat-file -s "$sha" 2>/dev/null; done | \
    awk '{sum += $1} END {print sum + 0}')
  echo "$size $branch"
done | sort -n | awk '{printf "%10.2f MiB  %s\n", $1 / 1024 / 1024, $2}'

这两个脚本我都放在服务器和本地反复用过，没什么大坑。唯一要留意的是，如果分支名里包含空格（Git其实是允许的），for循环按空格切分会出问题；不过绝大多数仓库不会这么干，真遇到了可以用while IFS= read -r branch替代。

4.3 排行榜怎么看：阈值和判断思路

拿到排行榜，怎么判断哪些分支需要治理？我通常按这个思路走：

• 总量小于100 MiB：属于正常范围，基本不用管。
• 总量100 MiB到500 MiB：值得关注，看一下Top blobs里是否有明显的大文件。
• 总量超过500 MiB：强烈建议进一步查独有增量，如果独有增量也很大，基本可以断定这个分支往历史里塞过大东西。

组合判断是最有用的：一个分支总量大但独有增量很小，说明它只是继承了主分支的庞杂历史，本身没有“额外作案”；相反，如果总量看起来不大，但独有增量占了大头，那才是真正需要处理的对象。我用这套方法定位过好几个“悄悄塞进2GB数据集”的功能分支，证据摆出来，提交的同学也很服气。

5. 统计之后怎么治理：大分支的清理与回收

5.1 大分支是怎么变大的：三个常见成因

统计完之后，通常会发现大分支的成因无非是下面几种：

第一种，大文件进入历史。 最常见。某个同学在开发AI功能时把模型权重文件.h5、.pt直接git add提交了，或者设计师把几十MB的素材原图放进了仓库。最典型的是，文件在后来的提交里被删除了，但Git历史仍然保留着它的所有历史版本，仓库体积并不会因为删除而下降。

第二种，长期未合并的长寿分支。 一条功能分支从主分支分出来之后，开发了几个月才合并，期间主分支还在不断更新，分支上反复merge主干，导致历史里堆积了大量重复对象。即使最终合并了，分支历史里那些膨胀的中间状态依然留在对象库里。

第三种，反复merge和cherry-pick造成的冗余。 团队规模一大，多分支并行开发，经常出现同一个commit被拣到多个分支的场景。这些操作本身是正常的，但长期积累下来，对象库里会出现大量几乎相同、只有细微差异的blob，把仓库体积一点点推高。

5.2 删除分支和gc：空间并不会马上回来

定位到大分支后，最简单直接的操作就是删除分支。但很多人删完一看，磁盘空间几乎没变，于是抱怨“Git真坑”。其实这是误解，原因是：

删除分支只是删掉了一个引用，对象仍然被reflog持有。Git的reflog会记录引用在一定时间内的历史变动，默认保留90天。如果你不清理reflog，那些对象就不会被当作垃圾回收。

完整的释放流程是这样的：

bash复制# 1. 删除本地分支
git branch -D feature/ai-model

# 2. 删除远程分支（如果已推送）
git push origin --delete feature/ai-model

# 3. 清理所有reflog记录
git reflog expire --expire=now --all

# 4. 立即gc并清空所有悬空对象
git gc --prune=now

执行完再跑一次git count-objects -vH，如果之前那个大分支确实是仓库膨胀的主要来源，size-pack会有肉眼可见的下降。

这里必须强调：--prune=now和reflog expire --expire=now都是完全不可逆的操作，误操作后想找回对象基本不可能。我的建议是先把这个仓库完整备份一份，或者至少用git clone --mirror打一个镜像包，再执行清理。另外，如果你在IDE（比如VS Code）里看不到已经被别人删除的远程分支，那只是本地ref缓存的问题，执行git fetch --prune就能清理掉过期的远程引用，这是两件不同的事。

5.3 历史重写：filter-repo的适用边界

单纯的删除分支解决不了“大文件在历史里”的问题。如果前面Top大文件查出来仓库里躺着几个几百MB的模型文件，而且它们出现在很多历史commit里，那就需要考虑重写历史了。

目前官方推荐的工具是git filter-repo，它比老古董filter-branch快得多也安全得多。示例：把历史中所有超过50MB的blob对象删掉：

bash复制pip install git-filter-repo
git filter-repo --strip-blobs-bigger-than 50M

或者只清理特定文件：

bash复制git filter-repo --path-glob '*.zip' --invert-paths

但我要泼一盆冷水：历史重写是“核武器”，付出代价远比你想的大。 重写历史后，所有基于旧历史的本地clone都需要重新拉取，任何正在开发的本地分支都可能因为历史不匹配而变成孤儿；如果仓库已经发布到公开平台，很多外部PR和评论信息都会受影响。我的判断标准是：仓库还没合并过太多外部提交、团队规模不大、或者大文件严重影响使用，才值得重写；否则优先考虑归档、拆分仓库，或者用LFS接管大文件，而不是强行改历史。

6. 统计分支大小时常见的坑与心得

6.1 为什么统计结果和“磁盘占用”对不上

很多人在跑完统计后满脸疑惑：“脚本不是说我这个分支有1.2GB吗，怎么删掉它之后磁盘才释放了300MB？”

这非常正常。前面脚本统计的是blob原始大小，也就是文件内容未压缩的总和；而磁盘上packfile里的对象是经过delta压缩和zlib压缩的，实际占用可能远小于原始大小。一个1GB几乎不可压缩的视频文件和一个1GB长满重复模式的文本文件，在packfile里的占用可能相差数倍。所以：

• 想衡量“谁引入了多少内容”，看原始blob大小；
• 想衡量“删除后磁盘能释放多少”，Gitee容量看gc前后的size-pack变化，脚本数据只能当参考。

6.2 packfile和delta压缩：为什么统计结果会“变”

同一个仓库，这周跑统计和下周跑统计，结果可能有出入，原因不一定是有人push了新代码，而是gc/repack改变了对象库的存储布局。delta压缩会重新配对不同版本之间的增量关系，导致packfile的总大小发生变化，但对象集合并没有实质变化。

如果你想拿到一个稳定、可横向对比的指标，就用rev-list --objects加总blob原始大小，这个值不受pack策略影响，只取决于对象集合本身。我平时在团队里汇报“分支体积变化趋势”，用的就是这个口径。

6.3 裸仓库、远端分支和Windows环境下的注意点

有几个使用场景值得单独提醒：

• 裸仓库（bare repo）：服务器上常见的xxx.git目录。因为没有工作树，命令完全可以跑，只是du的对象要直接指向裸仓库目录本身。
• 远端分支：如果你在本地clone了远程仓库，想看origin上各分支在本地缓存的对象情况，把脚本里的refs/heads/换成refs/remotes/origin/即可。
• Windows用户：建议统一用Git Bash来跑这些脚本，cmd和PowerShell对管道、awk语法的兼容性经常出幺蛾子。脚本里的sort -n在Git Bash环境里行为正常，不要切到Windows自带的sort。
• 超大仓库：如果仓库已经大到连本地完整clone都很困难，建议不要在本地做精确统计，直接拿服务器上的裸仓库跑，或者结合git-sizer先整体扫描，避免陷入“仓库太大没法clone，没法clone就没法统计”的死循环。

最后再分享一个我自己的习惯：把第4.2节的排行榜脚本放到一台常驻服务器上，用计划任务每周自动跑一次，把结果追加到日志文件。哪周突然冒出一个几百MiB的新分支，马上就能发现。早期干预的成本，永远比重写历史的成本低得多。如果只是想快速验证某个分支里是不是有大文件，也不用写脚本，直接跑一下第3.3节的Top blobs命令，10秒内就能看到答案。