在Bitbucket上托管Git时，硬限制为2 GB-如果超出该限制，则您只能对存储库进行只读访问。 例如，为防止这种情况，您可以追溯地从提交中删除大文件夹或文件。 但在其他情况下（如果访问数据已进入历史记录或node_modules已滑回主数据库），则必须追溯性地操纵Git的历史，这与其性质背道而驰。
Bitbucket撰写了有关此内容的详细文章。 为了遍历整个案例，我们首先创建一个新的存储库:
然后，将存储库克隆到本地计算机上的空文件夹中:
6ab7686fc508ce87c52b10bb5d01ee51
现在，我们创建两个带有随机内容文件的子文件夹:
6ab7686fc508ce87c52b10bb5d01ee51
我们现在正在推动大师:
6ab7686fc508ce87c52b10bb5d01ee51
现在我们几乎达到了Bitbucket上2 GB的硬限制:
我们也可以在本地检查（请参阅“尺寸包装”）:
6ab7686fc508ce87c52b10bb5d01ee51
现在的任务是追溯地从存储库中删除“ foo”，以将其大小减半。 为此，我们首先编辑当前HEAD并将文件夹写入gitignore:
6ab7686fc508ce87c52b10bb5d01ee51
最后，我们在BFG Repo Cleaner的帮助下删除该文件夹（BFG需要系统上的当前JRE作为系统要求）:
6ab7686fc508ce87c52b10bb5d01ee51
现在我们可以在本地看到结果:
6ab7686fc508ce87c52b10bb5d01ee51
但是在Bitbucket上，存储库的大小尚未更改，因为垃圾回收器尚未远程执行，并且Bitbucket不会在每次推送时执行“ git gc”:
支持也证实了这一点:
因此，最好直接将请求发送到support@bitbucket.org，以在存储库中手动运行“ git gc”。 短时间后，支持团队也完成了此操作:
如果将存储库“新”移动到另一台计算机，则磁盘上最终将只有0.9 GB。 如果某人在本地具有1.8 GB版本，则先使用“ git pull”再加上“ git gc”就足够了。