体积治理的四个阶段
仓库体积治理按「定位、归因、治理、防复发」推进：先找出体积在哪里，再判断为什么会有，然后选择迁移大文件存储、从历史中移除或改由制品库分发，最后用忽略规则与提交前检查防止复发。体积问题通常需要多轮才能收敛，指望一次处理到底并不现实。
基本信息
| 定位 | 用对象统计与包校验找出大对象 |
|---|---|
| 归因 | 素材、构建产物、依赖缓存、历史误提交 |
| 治理 | 迁移大文件存储、历史移除、制品库分流 |
| 防复发 | 忽略规则、提交前体积检查、评审清单 |
| 执行方式 | 先在副本上验证，再对主仓库执行 |
典型使用场景
- 克隆速度明显下降，需要找出体积来源
- 新人入职或流水线频繁拉取，体积成本被放大
- 历史中误提交过大型二进制文件
- 素材或模型文件需要纳入版本化管理
- 制定防止复发的规范与检查点
治理命令组合
治理命令组合
git count-objects -vH # 先看体积构成
git verify-pack -v .git/objects/pack/*.idx | sort -k3 -n | tail -10 # 找出最大的对象
git rev-list --objects --all | head -20 # 浏览对象与路径的对应
git lfs migrate info --everything # 统计可迁移的大文件类型治理路线
| 目标 | 手段 | 适用情形 |
|---|---|---|
| 保留但外置 | 迁移到大文件存储 | 素材与二进制仍需要版本化 |
| 彻底移除 | 重写历史删除文件 | 误提交且确实不需要保留 |
| 分流 | 改用制品库分发 | 构建产物与依赖缓存 |
| 防复发 | 忽略规则与提交前检查 | 所有仓库都建议配置 |
每次治理之后先在副本上验证克隆与构建，再对主仓库执行；体积问题往往需要多轮才能收敛，别指望一次到位。
从当前分支删除文件不会减小体积，历史里的那份对象依然存在。要真正瘦身必须处理历史，并通知所有协作者重新克隆或同步。