我的问题与此问题相同。 Remove large .pack file created by git
我按照这里列出的所有步骤：https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery，并尝试了此accepted answer中列出的所有步骤。但是，包文件的大小仍然很大。
之前：
count: 0
size: 0
in-pack: 2259
packs: 1
size-pack: 67333
prune-packable: 0
garbage: 0
size-garbage: 0
后：
count: 0
size: 0
in-pack: 2259
packs: 1
size-pack: 67333
prune-packable: 0
garbage: 0
size-garbage: 0
我仍然可以运行这个命令：git verify-pack -v .git/objects/pack/pack-xxx.idx | sort -k 3 -n | tail -3并查看三个最大的文件及其相应的提交但是当我运行git log --oneline --branches -- <large_file_name>时，没有提交引用该文件的提交，这可能是因为我重写了提交的历史记录。显然，我似乎已经搞砸了。
我的问题是，如何解决有关大型.pack文件的问题？
...当我运行
git log --oneline --branches -- <large_file_name>时，没有提交引用该文件的提交，这可能是因为我重写了提交的历史...
那很好（假设这是你的意图）。您现在需要做的是确保没有其他外部引用到达使用该文件的提交。
使用--branches告诉git log或git rev-list1查看所有分支名称引用，即refs/heads/下的所有内容。但是在refs/tags/下可能会有标签名称引用，所以你应该在那里查看。甚至可能有其他参考，所以你应该检查所有参考。最简单的方法是使用--all而不是--branches：查看所有引用。
但这也错过了reflogs。每个引用都有（至少可能）一个reflog。要使用reflogs，请使用-g或--walk-reflogs。请注意，您必须单独执行此操作。如果存在引用提交的reflog条目，则可以手动使其过期;或者你可以使用刚刚过期批发所有reflogs的强力方法（这有点危险，因为reflogs是你的主要安全网，但是你在原始存储库的副本上做了所有这些，对吧？:-)） 。
请注意，当您使用git filter-branch“重写历史记录”时，您真正将所有历史记录复制到新历史记录中。因此，您可以暂时将存储库大小增加到大约两倍，具体取决于您在过滤器中执行的操作。删除旧的reflog并删除refs/original/命名空间下保存的原始引用，然后进行垃圾回收，应该将内容缩小到适当的大小。
另请注意，如果包文件具有相应的.keep文件，即使在构建涵盖所有内容的新包之后，Git也不会丢弃保留的包。任何.keep文件都是手动创建的，如果合适，必须手动删除。
1这两个命令，git log和git rev-list，实际上只是一个命令，由一个源文件builtin/log.c构建。他们有不同的入口点，设置一些不同的默认选项，如果你没有命名任何其他起点，git log将从HEAD开始，而git rev-list需要一些起点。