我将一些大的二进制文件签入到 git 存储库中。我注意到它变得非常缓慢。响应根目录中的git status . 最多需要 4-5 秒。所以我决定用git filter-branch --tree-filter "rm -f web/libs/*.*jar" HEAD 和类似的命令清理存储库。但它们最多需要几个小时才能完成。
当这些命令正在运行时，我还能使用我的存储库吗？
【问题讨论】：
标签： git version-control git-filter-branch git-rewrite-history
您可以可能通过将 filter-branch 进程发送到 shell 会话的后台继续在您的 repo 中工作，或者打开另一个终端并以这种方式继续使用您的 repo , 但我强烈建议您不要这样做，如果您尝试这样做，可能会在您的 repo 中引起很多问题。
再一次，Git 可能会在过滤器分支期间锁定某些文件（例如索引），因此如果您在过滤器分支期间尝试非过滤器分支操作，它可能会抛出一堆错误。
不要为此使用树过滤器，正如您所见，它非常慢，因为它必须将每个提交检出到工作副本中。改用索引过滤器，如recommended in the filter-branch documentation，因为它不需要检查每个提交，因此它运行得更快：
git filter-branch --index-filter '
git rm --cached --ignore-unmatch web/libs/*.*jar
' HEAD
您还可以通过传递一系列导致 HEAD 的提交来加速过滤器分支，而不是过滤所有提交。例如，以下将过滤最后 20 或 21 次提交：
git filter-branch --index-filter '
git rm --cached --ignore-unmatch web/libs/*.*jar
' HEAD~20..HEAD
--index-filter <command>这是重写索引的过滤器。它类似于树过滤器，但不检查树，这使得它更快。经常与
git rm --cached --ignore-unmatch ...一起使用，请参见下面的示例。对于毛茸茸的情况，请参阅git-update-index(1)。
将
--index-filter与git rm结合使用会产生明显更快的版本。与使用rm filename一样，如果文件不在提交树中，git rm --cached filename将失败。如果你想“完全忘记”一个文件，它什么时候进入历史都没有关系，所以我们也加上--ignore-unmatch：git filter-branch --index-filter ' git rm --cached --ignore-unmatch filename ' HEAD
或者您可以尝试使用 BFG 工具，as VonC recommended。
【讨论】：
速度是你的问题，我写了BFG 是为了更快。它几乎肯定会在不到半分钟的时间内完成，而不是几个小时。
你应该仔细关注usage instructions，但核心部分是这样的：
$ java -jar bfg.jar --delete-files *.jar my-repo.git
这将删除存储库历史记录中您当前未在最新提交中使用的所有 jar。
BFG 通常至少比运行10-50x 快git filter-branch，并且通常更易于使用。如果您决定使用git filter-branch，您可能希望看到我不久前写的关于如何让它运行得更快一点的 SO 答案：https://stackoverflow.com/a/16154016/438886
无论您使用git filter-branch 还是 BFG，您真的不应该在历史记录被重写时在存储库上工作 - 但是，对于 BFG，这段时间将只是一个几秒钟。
全面披露：我是 BFG Repo-Cleaner 的作者。
【讨论】：