仓库回收怎么调
垃圾回收会合并打包对象并清理不再可达的对象，自动回收的触发阈值由配置项控制。把自动触发关掉、改用维护计划，是大仓库更可控的做法：回收时机明确、性能影响可以预期。
基本信息
| 手动执行 | 执行常规回收，附加立即清理选项时需要格外谨慎 |
|---|---|
| 关闭自动 | 把自动回收阈值配置为 0，交由维护计划管理 |
| 清理期限 | 悬空对象默认保留两周，期限内仍可找回 |
| 增量维护 | 维护任务可按单项执行，便于安排到低峰时段 |
| 触发机制 | 对象数量达到阈值时自动打包 |
典型使用场景
- 仓库对象文件过多导致日常操作变慢
- 频繁拉取与提交之后需要整理打包
- 归档或迁移仓库前压缩体积
- 大仓库把回收安排在业务低峰时段
- 排查仓库体积异常增长的原因
常用示例
常用示例
git gc --quiet # 常规回收，影响较小
git count-objects -vH # 查看对象与打包文件的实际占用
git config gc.auto 0 # 关闭自动触发
git config gc.pruneExpire '2.weeks.ago' # 保留两周内的悬空对象
git maintenance run --task=gc # 作为维护任务手动执行
git maintenance start # 交给系统计划任务管理配置项与作用
| 配置项 | 作用 |
|---|---|
| gc.auto | 对象数量达到阈值时自动回收，设为 0 则关闭 |
| gc.pruneExpire | 悬空对象的保留期限 |
| 彻底重打包 | 更彻底但耗时明显增加，大仓库收益有限 |
| 维护任务 | 按任务拆分并可在后台计划执行 |
默认保留两周内的悬空对象，是为了给误删的分支与提交留回旋余地，这也是本地日志能救回误操作的原因。
立即清理会把悬空对象直接删除，做历史恢复或取证之前不要执行，先确认没有还需要找回的内容。
回收过程会重写打包文件，磁盘占用可能短暂上升，空间紧张时先留出余量再执行。
大仓库把回收交给计划任务并安排在低峰时段，比在提交过程中被自动触发更不影响日常操作。