GitLab 仓库整理是什么
GitLab 在推送后会按平台条件自动对仓库做整理（gc、repack 等），控制对象碎片与体积；管理员也可以在项目或实例层面手动触发 Housekeeping。排「仓库体积异常」时，先确认平台整理是否已完成，再谈内容治理——整理只搬运与压缩已有对象，不会让历史里的大文件凭空消失。自建实例运维要理解触发条件与耗时特征。
基本信息
| 自动触发 | 推送达到平台设定的条件后自动执行整理 |
|---|---|
| 手动入口 | 项目 / 管理中心提供 Housekeeping（权限按平台版本） |
| 执行内容 | gc、repack 与陈旧数据清理 |
| 观察指标 | 体积与对象数在整理后下降才说明生效 |
| 耗时特征 | 与仓库规模相关，大仓执行期间性能可能波动 |
| 红线 | 不要进平台数据目录手工跑 gc，容器化部署会被覆盖 |
典型使用场景
- 体积治理收尾：历史重写或大文件清理后触发整理，让体积下降见效
- 排错等待：推送后整理期间命令变慢，先确认状态再下结论
- 定期巡检：管理员对热点项目手动触发整理
- 迁移对照：迁出前整理一次，方便体积前后对比
- 容量告警：磁盘告警时定位体积异常项目并处理
- 归档前置：项目归档前整理并核对对象数
体积观测
体积观测
git clone --mirror https://gitlab.example.com/group/app.git app-mirror.git
git -C app-mirror.git count-objects -vH # 查看镜像体积与对象数量
git -C app-mirror.git gc --quiet # 本地镜像整理（不代表平台侧动作）观察项与处理
| 指标 | 正常表现 | 异常处理 |
|---|---|---|
| 仓库体积 | 整理后下降 | 不降先查历史大对象 |
| 对象数 | 碎片减少 | 仍偏高时评估重写 |
| 推送体验 | 整理期可能变慢 | 大仓避开高峰手动触发 |
| 磁盘占用 | 平台侧稳定 | 持续增长做内容治理 |
不要直接在平台数据目录手工跑 gc 作为常规手段：容器化部署由平台托管，手工操作可能被覆盖。
大项目的手动整理安排在低峰时段执行，并提前告知团队期间 clone 与推送可能变慢。
整理与内容治理是两件事：前者压实时体积，后者减少历史内容，配合使用才能持续见效。