仓库瘦身方法
问题
-
为什么瘦身？
- 由于每个人都必须下载文件，因此获取代码库的速度变慢。
- 它们占用服务器上的大量存储空间。
- 会达到Git仓库的存储限制。
- 个人电脑硬盘空间有限，仓库较多时，占用了大量存储空间。
-
为什么二进制大文件是个问题？
- 在 git 中，所有和你共用一个库的人，当他们把库下载下来时，他们会得到你这个项目的完整历史记录。一般情况下这没什么问题——真正的代码只占很少体积，但拥有完整的历史记录使你能够实施分布式的合作、快速得到 diff 结果以及更多的便利——但项目的历史记录会慢慢膨胀。如果你提交了大文件——比如 100MB 以上——你仓库的体积会飞速增长，并且当其他人 clone 这个仓库的时候，他们要下载的数据就更多了。最终你会意识到你犯了一个错误，但是就算你决定要通过一个 commit 来删除这些文件，它们其实还在那儿，在你的历史数据中，下载整个仓库所花的时间不会有任何变化
方案
- Git 命令
- git-filter-branch 重写存储库会删除不需要的历史记录，从而使存储库更小
- git filter-repo 是用于快速重写Git存储库历史记录的工具。
- gitlab官方文档 https://docs.gitlab.com/ee/user/project/repository/reducing_the_repo_size_using_git.html#repository-cleanup
- git-filter-repo用法 https://htmlpreview.github.io/?https://github.com/newren/git-filter-repo/blob/docs/html/git-filter-repo.html#EXAMPLES
- BFG Repo-Cleaner
- git-filter-branch 的替代品 用 Scala 写 BFG Repo-Cleaner ，Scala 很适合去处理 git 的不可变数据结构，并且能利用并行开发的优势。
- 速度更快
- 在 git 中，所有文件和文件夹的数据都只存储一次，并且每个都会有一个独一无二的 id——git-id。如果大量的 commit 都没有修改某个文件，那么这个文件只会被保存一次。如果这个文件有两个版本，并且需要在两个版本间来回切换，这个文件只会存储两次，每个版本各一次。所以，如果一个文件只存储一次，因为它出现在 100 个 commit 中，就要对它清理 100 次，这肯定是不现实的。BFG 只对 git 库中的每个对象清理一次，然后记住它的 git-id，以后遇到它，不把它计算在内就行了。我们对功能做了限制——git-filter-branch 能让你做任何事，而 BFG 不行——以此换来性能上的巨大改进。
速度的提升还受益于没有进程间的切换（JVM 会搞定一切，不需要在 C 代码和 bash 代码间来回切），以及能充分利用你的多核电脑。我很高兴看到 BFG 会使你所有的处理器核发烫，每个核都在尽其所能地删除文件和目录——但是很不幸 git-filter-branch 只能串行处理工作，一个接一个地处理 commit——前一个处理完之前，无法开始下一个。BFG 的速度明显是一大优势。
- 在 git 中，所有文件和文件夹的数据都只存储一次，并且每个都会有一个独一无二的 id——git-id。如果大量的 commit 都没有修改某个文件，那么这个文件只会被保存一次。如果这个文件有两个版本，并且需要在两个版本间来回切换，这个文件只会存储两次，每个版本各一次。所以，如果一个文件只存储一次，因为它出现在 100 个 commit 中，就要对它清理 100 次，这肯定是不现实的。BFG 只对 git 库中的每个对象清理一次，然后记住它的 git-id，以后遇到它，不把它计算在内就行了。我们对功能做了限制——git-filter-branch 能让你做任何事，而 BFG 不行——以此换来性能上的巨大改进。
实现(选择BFG Repo-Cleane 操作简单 速度更快)
- BFG Repo-Cleaner （https://rtyley.github.io/bfg-repo-cleaner/）
- 首先删除不想要文件 并提交
rm file-to-delete
git commit -m "删除大文件"
git push" - 下载官网的程序包。例如我这里下载的为bfg-1.14.0.jar，之后将程序包放到一个项目文件夹里，重命名为bfg.jar 。这是一个Java程序，使用的话需要安装Java运行环境（https://www.java.com/en/download/manual.jsp）。
- clone自己的git repo，使用--mirror参数。
git clone --mirror git@github.com:12134/XXXX.git - 清除大文件、文件夹和检索大文件 命令
java -jar bfg.jar --delete-files 123.png XXXX.git (删除文件)
java -jar bfg.jar --delete-folders Pods XXXX.git （删除文件夹）
java -jar bfg.jar --strip-blobs-bigger-than 100M XXXX.git(大于100M文件) - 执行完 有一个问题，这种情况bfg会保护当前版本(HEAD所指的版本)，不去清理。提示如下。
These are your protected commits, and so their contents will NOT be altered: commit ******* (protected by 'HEAD')
如果说当前版本已经没有问题，那么这么使用没有问题。
但是我的当前版本也是有需要删除的文件的，在谷歌搜索了一下，找到了解决方法。
在命令行下加入--no-blob-protection命令，可以解除保护。使用的命令如下。
java -jar bfg.jar --delete-files 123.png XXXX.git --no-blob-protection
java -jar bfg.jar --delete-folders Pods XXXX.git --no-blob-protection
- 首先删除不想要文件 并提交
- 在完成上面的指令后，实际上这些数据/文件并没有被直接删除，这时候需要使用git gc指令来清除。
cd XXXX.git
git reflog expire --expire=now --all && git gc --prune=now --aggressive - 最后，更新完本地仓库后，将数据推送到GitHub远程仓库。按照官网描述，由于之前使用了--mirror参数，推送时会推送所有内容。(push完成之后放弃旧存储库副本重新clone)
git push
实现结果
需要测试请上码云建仓库测试
GitHub会报下面的错
[remote rejected] refs/pull/1/head -> refs/pull/1/head (deny updating a hidden ref)
问题详情（https://stackoverflow.com/questions/34265266/remote-rejected-errors-after-mirroring-a-git-repository）
GitHub所有已清除的拉请求历史记录都没有被清除。如果希望你的拉请求，以及它们引用的所有提交/历史记录都删除，那么在GitHub上的总回购大小可以缩小(除了已经缩小的默认克隆的大小之外)，需要联系GitHub支持
WechatIMG219.png
WechatIMG221.png
WechatIMG222.png
