如何清理远程 git repo 中的垃圾
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/27867775/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to cleanup garbage in remote git repo
提问by stevebot
I recently ran into a size limit with my Bitbucket repo. I followed the countless other questions answering how to clean up your git repo and ended up using BFG to remove some bad commits.
我最近在使用 Bitbucket 存储库时遇到了大小限制。我跟着无数其他问题回答了如何清理你的 git repo 并最终使用 BFG 来删除一些错误的提交。
This worked great, however, I noticed that after running a git count, there was a large amount of space sitting in garbage. So I ran a simple git gc. However, that did nothing to clean up the garbage.
这很有效，但是，我注意到在运行 git count 后，垃圾中有大量空间。所以我运行了一个简单的 git gc。然而，这并没有清理垃圾。
After some digging I found the following command:
经过一番挖掘，我发现了以下命令：
git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 \
-c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@"
Running this led to the garbage being cleaned up locally. However, I still have the issue of the remote repo. Do I now need to get Bitbucket to run this command on my remote repo, or is there a way to push this change to the repository?
运行这个导致垃圾被本地清理。但是，我仍然有远程回购的问题。我现在是否需要让 Bitbucket 在我的远程存储库上运行此命令，或者有没有办法将此更改推送到存储库？
采纳答案by stevebot
If anyone else is experiencing this, the answer turned out to be yes.
如果其他人也遇到过这种情况，那么答案是肯定的。
Bitbucket support ran the following:
Bitbucket 支持运行以下内容：
git reflog expire --expire="1 hour" --all
git reflog expire --expire-unreachable="1 hour" --all
git prune --expire="1 hour" -v
git gc --aggressive --prune="1 hour"
The before and after reduced the remote repo size from over 2GB, to under 1GB.
之前和之后的远程仓库大小从 2GB 以上减少到 1GB 以下。
回答by Jan ?ankowski
We think we had the same problem today and were able to solve it without contacting Bitbucket support, as below. Note that the method discards last commit from the repo- so you probably want to have its backup.
我们认为我们今天遇到了同样的问题，并且能够在不联系 Bitbucket 支持的情况下解决它，如下所示。请注意，该方法会丢弃 repo 中的最后一次提交- 因此您可能想要备份。
Bitbucket reported that our repo was about 2.1GB, while when cloned, it only took about 250MB locally. From this, we concluded that it's most likely from big files in unreachable commits (thanks to this answer).
Bitbucket 报告我们的 repo 大约为 2.1GB，而在克隆时，它在本地只占用了大约 250MB。由此，我们得出结论，它很可能来自无法访问的提交中的大文件（感谢这个答案）。
This is how to see unreachable commits locally,?where we don't take into account?reachability via reflog:
这是如何在本地查看无法访问的提交？我们不考虑的地方？通过 reflog 的可达性：
git fsck --unreachable --no-reflog
git fsck --unreachable --no-reflog
Locally, unreachable commits can be cleaned with:
在本地，可以使用以下方法清除无法访问的提交：
git reflog expire --expire-unreachable="now" --all
git prune --expire="now" -v
git gc --aggressive --prune="now"
We cannot however run any of these commands remotely on Bitbucket. But, they say on the page about reducing repo size(section Remove the repository limitation) that they run git gcthemselves in response to doing git reset --hard HEAD~1(which discards last commit) followed by git push -f. Also, they say in the section Garbage collecting dead datathat one can try the sequence:?git reflog expire --expire=now --all,?git gc --prune=now,?git push --all --force. Given all this, I decided to try the following locally, hoping it'd cut out the reflog and do a prune locally, and then push them to remote Bitbucket repository, on which it'd start a gc:
但是，我们无法在 Bitbucket 上远程运行任何这些命令。但是，他们在关于减少存储库大小的页面上说（删除存储库限制部分），他们自己运行git gc以响应执行git reset --hard HEAD~1（丢弃最后一次提交），然后是git push -f. 此外，他们在垃圾收集死数据一节中说，可以尝试以下序列：？git reflog expire --expire=now --all，？git gc --prune=now，？git push --all --force. 考虑到这一切，我决定在本地尝试以下操作，希望它可以删除 reflog 并在本地进行修剪，然后将它们推送到远程 Bitbucket 存储库，并在其上启动 gc：
git reflog expire --expire-unreachable="30m" --all
git prune --expire="30m" -v
git gc --prune="30m"
git reset --hard HEAD~1
git push -f
This worked, repo size immediately went from 2.1GB to ca. 250MB. :)
这奏效了，repo 大小立即从 2.1GB 变成了大约。250MB。:)
Note that the time param to expire / expire-unreachable / prune sets the expiration cut-off point measuring from now back. So e.g. "now" means expire / prune everything, and "30m" means except for changes in last 30 minutes.
请注意，过期/过期无法访问/修剪的时间参数设置了从现在开始测量的过期截止点。因此，例如“现在”表示过期/修剪所有内容，“30m”表示过去 30 分钟内的更改除外。
