为什么要盯仓库体积
大文件与二进制检查针对的是「不该入库的东西进了版本库」：构建产物、数据集、媒体文件一旦提交，体积会被永久记进 Git 历史，克隆、备份与 CI 检出统统变慢，而二进制又几乎无法逐行评审。判断口径很简单——这个文件能不能由流水线生成，或者能不能改放到对象存储与制品库。
基本信息
| 评审对象 | 提交里的二进制、压缩包、模型权重、数据集、媒体素材 |
|---|---|
| 判断口径 | 能生成走流水线；大素材走 Git LFS 或对象存储 |
| 检查方式 | 提交前看体积，超过约定阈值即拦截 |
| 常用工具 | Git LFS、pre-commit 钩子、仓库体积告警 |
典型使用场景
- 前端仓库出现打包产物：dist 应由流水线产出，不入库
- 后端仓库出现 jar 或编译中间产物：本地构建结果不该进提交
- 需要随代码发布的模型或数据集：放对象存储，仓库只留下载脚本
- 确实需要版本化的二进制资源：走 Git LFS 并确认配额
- 图片与图标资源：压缩后再入库，必要时统一尺寸
入库判断与处置
| 文件类型 | 推荐处置 | 说明 |
|---|---|---|
| 编译产物：dist、jar、可执行文件 | 不入库，由 CI 构建 | 每次提交都会产生大量无意义差异 |
| 模型权重、数据集、视频 | 对象存储或 Git LFS | 仓库只保留指针与下载方式 |
| 图片、字体等静态资源 | 压缩后入库，控制数量 | 单文件过大时同样考虑 LFS |
| 测试夹具中的小样本 | 可入库，注明来源 | 体积小且被测试直接引用 |
提交前排查体积
提交前排查体积
# 本次工作区里体积最大的文件
git ls-files -z | xargs -0 du -h | sort -h | tail -20
git count-objects -vH # 仓库体积概览
git lfs track "*.psd" # 需要版本化的大素材交给 LFS
git rev-list --objects --all | git cat-file --batch-check | sort -k3 -n -r | head # 历史里的最大对象Git 历史不可逆：大文件一旦合入，后续删除也不会减小体积，清理要用 filter-repo 重写历史并强推，所有人需重新克隆。
评审时可以请作者回答三件事：这个文件能否由流水线生成、能否改从制品库下载、是否已经配置 LFS 与配额。