git - 从 Git 历史记录中删除二进制文件后，为什么我的存储库仍然很大？

Question

所以让我先说这个问题，我知道之前关于 Stackoverflow 主题的问题。事实上，我已经尝试了我能找到的所有解决方案，但我的仓库中有一个二进制文件拒绝删除并继续大大增加我的仓库大小。

我试过的方法，

David Underhill's script

Github's Howto

两者都是由 Darhuuk 对 Remove files from git repo completely 的回答推荐的

但是，在尝试了这两种解决方案后， script to find large files in git仍然找到有问题的二进制文件。但是来自 this answer 的脚本不再找到二进制文件的提交。这两个脚本都是由 this answer 建议的.

尝试删除后，repo 仍然是 44mb，这对于相对较小的源来说太大了。哪些建议大文件脚本正确地完成它的工作。我试过推到 github (我做了一个 fork 以防万一)然后做一个新的克隆来查看 repo 大小是否减少，但它仍然是相同的大小。

有人可以解释我做错了什么或提出替代方法吗？

我应该注意，我不仅对从本地存储库中修剪文件感兴趣，还希望能够在 Github 上修复远程存储库。

Answer 1

2017 年编辑:您可能应该查看 BFG Repo-Cleaner如果你正在阅读这篇文章。

令人尴尬的是，我的本地存储库没有缩小的原因是因为我在过滤器分支中使用了错误的文件路径。因此，虽然我感谢 J-16 SDiZ 和 CodeGnome 的回答，但我的问题是在椅子和键盘之间。

为了让这个问题不再是我愚蠢的纪念碑，并且对人们真正有用，我花时间写下了在修剪 repo 后必须经历的步骤，以便在 Github 上恢复 repo .希望这可以帮助某人解决问题。

删除违规文件

要删除有问题的文件，请运行下面的 shell 脚本，基于 Github remove sensitive data howto

#!/usr/bin/env bash
git filter-branch --index-filter 'git rm -r -q --cached --ignore-unmatch '$1'' --prune-empty --tag-name-filter cat -- --all

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now

我浏览了本地存储库中的每个分支并执行了此操作，但老实说我不确定是否需要这样做，(您不需要在每个分支上都执行此操作)但是下一步需要每个本地分支，所以记在脑子里。完成后，您应该会看到本地存储库的大小减少。您还应该能够在 CodeGnome 的答案中运行 blob 脚本并查看有问题的 blob 删除。如果没有，请仔细检查文件名和路径并确保它们是正确的。

什么 git filter-branch这里实际上是在 repo 中的每个提交中运行引号中列出的命令。

脚本的其余部分只是清除旧数据的任何缓存版本。

push 修剪后的 repo

现在本地存储库处于状态，您需要它的诀窍是将其备份到 Github 上。不幸的是，据我所知，无法从 Github 存储库中完全删除二进制数据，这里引用了 Github sensitive data howto

Be warned that force-pushing does not erase commits on the remote repo, it simply introduces new ones and moves the branch pointer to point to them. If you are worried about users accessing the bad commits directly via SHA1, you will have to delete the repo and recreate it.

您需要重新创建 Github 存储库很糟糕，但好消息是重新创建存储库实际上非常容易。痛苦的是，您还必须重新创建问题和 wiki 中的数据，我将在下面进行介绍。

我推荐的是在 github 中创建一个新的 repo，然后当你准备好时用你的旧 repo 将它切换出来。这可以通过将旧的重命名为“repo name old”，然后将新创建的 repo 的名称更改为“repo name”来完成。确保在创建新存储库时使用 README 取消选中初始化，否则您将不会处理干净的石板。

如果你完成了最后一步，你应该清理你的仓库并准备好。现在需要更改 Remote 以匹配新的 Github 存储库位置。我通过直接编辑 .git/config 文件来做到这一点，尽管我确信有人会告诉我这不是正确的做法。

在进行推送之前，请确保您在本地存储库中拥有要推送的所有分支和标签。准备好后，使用以下命令推送所有分支

git push --all
git push --tags

现在你应该有一个远程仓库来匹配你修剪过的本地仓库。仔细检查所有数据以防万一。

现在，如果您不必担心问题或 wiki，您就大功告成了。如果你继续阅读。

在维基上移动

Github wiki 只是与您的主存储库相关联的另一个存储库。因此，要开始在某处克隆您的旧 wiki 存储库。然后下一部分有点棘手，据我所知，您需要单击新存储库的 wiki 选项卡才能创建 wiki，但它会为新创建的 wiki 植入一个初始文件。所以我所做的，我不确定是否有更好的方法，是将 Remote 更改为新创建的 wiki 存储库并使用推送到新位置

git push --all --force

这里需要强制，否则 git 会提示当前分支的尖端不匹配。我认为这可能会使 git repo 中的初始页面处于分离状态，但它对 repo 大小的影响应该可以忽略不计。

转移问题

this answer对此给出了建议。 .但是看着 the script在答案中链接它看起来相当不完整，有一个用于评论导入的 TODO，我不知道它是否会带来问题的状态。

因此，鉴于我有一个相当小的未解决问题队列，而且我不介意丢失已解决的问题，我选择手动提交。请注意，在评论中适本地归因于其他人是不可能做到这一点的。因此，我认为对于一个更成熟的大型项目，您需要编写一个更强大的脚本来完成所有工作，但对于我的特定情况，这不是必需的。