我有一个带有大量分支的存储库，并且“git filter-branch ... -- --all”逐渐减慢（大约 400,000 次提交，大约运行 7 天）。但是单个分支上的“git filter-branch”可以显着提升性能（大约 5 天）。
使用以下算法在大量分支上并行化“过滤器分支”是否正确？
问候，格特
恭喜您找到了一种有趣的方法来并行执行git filter-branch-我认为原则上，您所描述的过程将成功地提供正确且内部一致的重写历史，尽管这绝对取决于您的命令在做什么--index-filter（例如，如果您正在做一些疯狂的事情，例如将随机数插入文件中，则生成的分支历史记录将显得完全独立）。
git filter-branch是一个非常强大的工具：它允许您对每个文件执行完全任意的操作，并在您的历史记录中提交——尽管这种灵活性听起来很吸引人，但它经常对你不利——你为此付出了沉重的执行时间。所以问题是——你需要那种灵活性吗？您能否更具体地说明您要实现的目标？
从 Git v1.9 开始，文档说明git filter-branch包含此建议（诚然是我自己贡献的，但经过 Git 邮件列表的审查！）：
git-filter-branch 允许您对 Git 历史进行复杂的 shell 脚本重写，但如果您只是删除不需要的数据（如大文件或密码），您可能不需要这种灵活性。对于这些操作，您可能需要考虑BFG Repo-Cleaner，它是 git-filter-branch 的基于 JVM 的替代品，对于这些用例通常至少快 10-50 倍，并且具有完全不同的特性
BFG 可以执行许多git filter-branch用于执行的任务 - 但速度要快得多- 部分原因是它使用了记忆，还因为它执行了清理任务的并行化，使其能够充分利用多核机器。这些因素结合在一起可以节省执行时间，而不是比并行filter-branch运行可能减少 30% 更好 - 事实上，运行时间减少通常更接近 98%，即50 倍或以上的加速。
谷歌浏览器工程师Elliot Glaysher 的评论：
使用此工具时，我能够在大约 10 分钟内将当前存储库缩小到约 500 兆字节。我手工制作的脚本在 3 天内达到 615 兆字节以进行比较。
总而言之，值得考虑 BFG 是否可以成为这项工作的更好工具。
全面披露：我是 BFG Repo-Cleaner 的作者。