当存储库已经非常接近 2GB 时，如何从所有 bitbucket git 历史记录中删除二进制文件？

Question

Bitbucket git repo 的大小限制为 2GB，现在我有一个 repo（我们称之为bigsize repo），由于大量二进制文件（扩展名为dll的msm ）. 它是如此接近限制，以至于我害怕涉及二进制文件的提交操作会将大小超过 2GB，因此提交将失败并且无法继续。

现在，如何通过减少 bigsize repo 大小来优化 go？

我正在考虑使用LFS 功能，但是 LFS 空间有 1GB 的限制，我担心这不足以使用这个 repo（因为大部分 repo 大小来自二进制文件我想存储在 LFS 中）。

因此，我正在考虑从存储库和历史记录中删除所有二进制文件（我不介意从源代码控制中丢失它们，因为它们在本地驱动器上），考虑到当前大小，如何最好地做到这一点我的大型回购？

我的攻击计划：

1. 确保对于 bigsize repo 上的所有分支（是的，我在这个巨大的 repo 上有多个分支），我已经删除了所有二进制文件（通过在 gitignore 中提交指定*.dll的提交并使用git rm -rf -cached命令）。 这是必需的，因为“默认情况下，BFG 不会修改您在 master（或“HEAD”）分支上的最新提交的内容，即使它会清除之前的所有提交。 ”
2. 然后使用 BFG delete-files 命令“重写历史记录”，以便减少 repo 大小。

该方法是否适用于非常接近 2GB 的存储库？ 我担心在第 1 步，当我使用git rm时，它会添加到历史记录并将 repo 大小推到 2GB 以上，因此会失败。

重要细节：

1. 我是存储库的唯一作者
2. 现在我是多个活跃的分支。 在整个历史中，有多个分支合并到主分支中
3. 我不使用 repo 进行讨论或代码审查，甚至不使用标签。 我只是将它用作单个分支，偶尔进行分支和合并

Answer 1

git filter-branch或 BFG已过时

对于 Git 2.22 或更高版本，请使用git filter-repo ：

git filter-repo --path your/big/file --invert-path

或者：

git filter-repo --strip-blobs-bigger-than 10M

Answer 2

这是我使用BFG repo clean解决问题的方法。 我把它写下来，以便对将来可能面临与我相同情况的人有所帮助。

甚至在开始之前，请确保您的所有分支都是“清晰的”，即：您想要的所有更改都被推送到它们各自的分支中。 让我们将我们巨大的 repo 命名为big repo，并假设它位于D:\MyCompany\big 。

此外，您可能想在实际处理生产存储库之前在玩具存储库上尝试此操作。

1. 将你的大仓库克隆到一个全新的文件夹（ git clone --mirror git@bitbucket.org:YourUserName/big.git ），确保这个新文件夹不在你原来的大仓库文件夹中。 您需要非常确定这是与D:\MyCompany\big完全不同的东西（因此您可以毫无畏惧地对其进行试验）。 假设这个文件夹是D:\big_work ，你将能够在克隆后找到D:\big_work\big.git文件夹。
2. 备份big.git文件夹到另一个地方，我们把它放在D:\backup 。

3. 确定您的二进制文件确实超出了 bitbucket（或您的 repo 提供商）提供的 LFS 限制。 在这里，我需要确定我的二进制文件大小小于 1GB。 为此，请通过 BFG 将 big.git 的big.git转换为 LFS。 在命令行：

   3.1。 cd D:\big_work

   3.2. java -jar <path to>bfg-xxxjar --convert-to-git-lfs "*.{dll, msm}" --no-blob-protection big.git里面有D:\big_work文件夹）

4. 现在检查D:\big_work\big.git\lfs文件夹的大小，是否超过 1GB？ 如果不是，您可以从此处的步骤 4 继续将二进制文件转换为lfs 。 无需阅读 rest。

5. 如果lfs文件夹超过 1GB，则必须从 repo 中删除二进制文件并重写历史记录。
6. 从D:big_work中删除big.git文件夹，然后从D:\backup中恢复它（您在步骤 2 中执行的备份）。

7. 这是最重要的一步：实际删除。 许多指南都讨论了为什么在执行此步骤之前首先确保提交是干净的（意味着当前 state 的存储库中没有更多的二进制文件）很重要。 但我确实发现诸如此类不必要且令人分心的建议。 因为我们已经非常清楚我们想要什么——也就是说，从我们的仓库中删除所有二进制文件，现在和过去，从所有分支中，合并或未合并，并且仓库应该看起来好像它从未被二进制文件污染在任何一个时间点——我们应该忽略这个警告。 为此，我们带来了我们的核武器no-blob-protection 。

   7.1。 cd D:\big_work

   7.2. java -jar <path to>bfg-xxxjar --delete-files "*.{dll,msm}" --no-blob-protection big.git

8. cd D:\big_work\big.git

9. git reflog expire --expire=now --all && git gc --prune=now --aggressive
10. git push
11. 现在 go 到您的 bitbucket大仓库，您应该会发现您的所有 dll 和 msms 已从所有分支和所有历史记录中删除。 这应该让您确信您已经做了正确的事情：正在删除二进制文件并保存您的存储库！
12. 请记住，您的原始大仓库位于D:\MyCompany\big并且您的 sourcetree 书签指向此文件夹，因此您需要首先删除 sourcetree 书签，并将D:\MyCompany\big重命名为D:\MyCompany\big_old我的D:\MyCompany\big_old 。 暂时不要删除big_old文件夹，因为即使您不希望二进制文件位于 repo 中，但您仍希望它们位于硬盘上，而big_old文件夹提供了自然备份。 在您确定它确实没有任何价值之后，您可以在将来的某个时间删除big_old文件夹。
13. 您需要再次将干净的 repo 克隆到硬盘上。 让我们将其克隆回D:\MyCompany\big文件夹以避免任何重大更改。
14. 将 sourcetree大repo 书签重新指向D:\MyCompany\big文件夹。
15. 不时根据需要逐渐将您需要的二进制文件从big_old到big文件夹中。
16. 您可能需要联系 bitbucket 支持，让他们运行垃圾收集操作以减小大小。

主要参考资料：

1. 适合新手的 BFG
2. 使用 BFG 将 repo 迁移到 Git LFS
3. BFG 回购清洁剂