仅做微小修改时git push极慢，git pack-objects耗时过长问题咨询

git pack-objects 推送场景执行逻辑 #

git push 流程中触发pack-objects的完整逻辑如下：

1. 本地git先和远程服务端交换全量refs列表，定位到远程分支的最新提交和本地待推送提交的共同祖先，确认需要打包传输的对象范围
2. pack-objects遍历本地对象库，筛选出所有待传输的对象
3. 为待传输对象匹配最优delta压缩基准，执行压缩生成thin pack包传输给远程

性能差异的核心原因 #

1. refs数量级差距是最大开销来源 #

你的私有服务端有300k个refs，是谷歌原生AOSP服务端的3倍，本地refs也达到3k是原生的2倍多。git在推送前的refs协商阶段需要遍历所有双方refs来匹配共同提交，refs量级增长后该遍历耗时会线性上升，这就是你这边44秒开销的核心组成。

2. 冗余对象拖慢对象遍历与delta匹配效率 #

你的私有仓库总大小5G比原生AOSP多1.5G，存在大量原生仓库没有的冗余提交、废弃对象。pack-objects扫描本地对象库、匹配delta基准的范围远大于原生仓库，耗时进一步升高。从日志也可以佐证：你的推送结果是Total 3 (delta 0)，原生AOSP是Total 3 (delta 2)，说明你的仓库没有找到合适的delta基准，对象索引或delta链存在优化空间。

3. 缺失位图索引优化 #

谷歌原生AOSP仓库默认开启了pack位图（bitmap）索引，pack-objects可以直接通过位图快速定位对象范围，不需要全量遍历refs和对象，这也是原生场景下pack-objects仅需0.05秒的关键优化点。

优化方案 #

1. 清理服务端和本地的废弃分支、临时标签，将refs数量降到和原生AOSP同量级
2. 执行git gc --aggressive --prune=all对本地仓库对象做全量整理，优化对象索引与delta链
3. 开启位图索引优化配置：

git config pack.writeBitmaps true
git config push.useBitmaps true

4. 调整pack内存限制，提升大仓库处理效率：

git config pack.deltaCacheSize 1g
git config pack.windowMemory 1g

内容的提问来源于stack exchange，提问作者demonguy