2017年编辑:如果您正在阅读此内容,您应该考虑查看BFG Repo-Cleaner。
非常尴尬的是,我的本地存储库未缩小的原因是我在filter-branch中使用了错误的文件路径。所以,我感谢J-16 SDiZ和CodeGnome提供的答案,但我的问题出现在了我的操作上。
为了使这个问题不再成为我愚蠢的纪念碑,而是对人们有用,我花时间编写了一些步骤,以便在修剪存储库后将其重新上传到Github。希望这能帮助到其他人。
删除有问题的文件
要删除有问题的文件,请运行下面的shell脚本,根据Github删除敏感数据指南。
#!/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 实际上是在每个提交中运行引号中列出的命令。
其余的脚本只是清除旧数据的任何缓存版本。
推送修剪后的仓库
现在本地代码库处于所需状态,关键是将其推回Github。不幸的是,据我所知,没有完全从Github仓库中删除二进制数据的方法,以下是Github敏感数据说明文档中的引用:
请注意,强制推送不会删除远程仓库中的提交,它只会引入新的提交并将分支指针移动到它们所指向的位置。如果您担心用户通过SHA1直接访问错误的提交,您将不得不删除仓库并重新创建它。
需要重新创建Github仓库是很糟糕的,但好消息是重新创建仓库实际上非常容易。痛苦之处在于,您还必须重新创建问题和wiki中的数据,下面我将详细介绍。
我建议的做法是在Github上创建一个新的仓库,并在准备好时将其替换为旧的仓库。这可以通过将旧仓库重命名为类似于“repo name old”的名称,然后将新创建的仓库的名称更改为“repo name”来完成。确保在创建新仓库时取消选中初始化README,否则将无法从干净的状态开始。
如果您完成了上一步,那么应该已经清理好并准备好使用了。现在需要更改远程以匹配新的Github仓库位置。我直接编辑.git/config文件来完成此操作,尽管我确定有人会告诉我这不是正确的方法。
在推送之前,请确保您在本地代码库中拥有所有要推送的分支和标签。一旦准备就绪,请使用以下方式推送所有分支:
git push --all
git push --tags
现在你应该有一个与你本地裁剪过的仓库相匹配的远程仓库。请再次检查所有数据,以防万一。
如果你没有问题或者wiki,那么你已经完成了。如果有,请继续阅读。
移动Wiki
Github Wiki只是与你的主要仓库相关联的另一个仓库。所以,为了开始工作,请在某个地方克隆你的旧Wiki仓库。接下来的部分有点棘手,据我所知,你需要点击你的新仓库的Wiki选项卡才能创建Wiki,但它会使用一个初始文件来填充新创建的Wiki。所以我做的是更改远程到新创建的Wiki仓库,并使用以下命令将其推送到新位置:
git push --all --force
之所以需要使用 force 是因为否则 git 会抱怨当前分支的 tip 不匹配。我认为这可能会让 git 仓库中的初始页面处于脱离状态,但对仓库大小的影响应该可以忽略不计。
迁移问题
此答案 中提供了一些建议。但是看到答案中链接的脚本,它似乎相当不完整,评论导入上有一个 TODO,而我也无法确定它是否会带过问题的状态。
因此,考虑到我有一个相当小的未解决问题队列,并且我不介意失去已关闭的问题,我选择手动搬迁。请注意,无法在评论中正确地归属其他人。因此,我认为对于一个更大、更成熟的项目,您需要编写一个更健壮的脚本来搬迁所有问题,但对于我的特定情况,这并不需要。