BitBucket远程仓库未缩减体积及本地远程差异咨询

操作与现象说明 #

执行的历史清理命令：

$ git gc
$ git filter-repo --replace-refs delete-no-add --strip-blobs-bigger-than 10M
$ git reflog expire --expire=now --all
$ git gc --aggressive --prune=now
$ git commit
$ git push origin master --force

操作前本地.git文件夹大小为2GB，操作后降至25MB；使用git clone --mirror repo.git克隆得到的镜像仓库体积也为25MB，但BitBucket远程仓库体积仍为2GB。

1. 操作存在的错误 #

• 多余的git commit：git filter-repo已经完成历史重写，此时执行git commit属于无效操作，会创建无意义的空提交（若工作区无变更），反而可能干扰重写后的历史结构。
• 仅推送master分支：若仓库存在其他分支、标签，这些引用未被重写和推送，远程仓库会保留对应分支的历史大文件对象。
• 错误使用--replace-refs delete-no-add参数：该参数会删除原分支引用但不添加重写后的新引用，可能导致本地分支引用异常，后续推送时无法正确覆盖远程的分支引用。
• 清理顺序不合理：先执行git gc对后续的历史重写没有帮助，应该在filter-repo完成历史重写后再执行gc操作。

2. 本地与远程仓库体积差异的原因 #

• 远程保留旧引用：BitBucket会保留仓库的所有分支、标签、旧提交引用（包括已关闭的Pull Request历史、归档分支等），只要这些引用存在，对应的大文件对象就不会被清理。
• 远程垃圾回收未触发：Git远程仓库不会自动立即清理废弃对象，BitBucket的垃圾回收有触发周期，需要等待平台自动执行，或手动在仓库后台触发（需管理员权限）。
• 未推送所有重写后的引用：仅推送了master分支，其他分支、标签的历史未被更新，远程依然保留这些分支的完整历史数据。
• 远程的备份/归档机制：BitBucket可能存在内部的备份或归档逻辑，暂时保留了旧的仓库版本数据，导致体积未及时下降。

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