虽然把大文件删除了,但是.git文件夹还是占用很大空间,查询资料发现是因为有些文件虽然被删除了,但是gitee、github还会保留它的历史日志。
.git\objects\pack里有大文件
首先,我们需要找出大文件。
找出排名前 3 的 pack 记录:
git verify-pack -v .git/objects/pack/pack-*.idx | sort -k 3 -g | tail -3
找出大文件所在的位置
git rev-list --objects --all | grep bd97bfde4d9a108d012dd1e4685ef8ad6e1ec0ea
处理大文件
git filter-branch --index-filter 'git rm --cached --ignore-unmatch uploads/files/5d37a3de481b1.pdf'
执行以下语句
rm -rf .git/refs/original
git reflog expire --expire=now --all
git fsck --full --unreachable
git repack -A -d
git gc --aggressive --prune=now
git push --force
博主因为不是一两个文件,实在整不动了,直接删库跑路了……
我做法是:
1、本地保留代码,然后删库
2、重新创建同名git路径的库
3、重新checkout一份代码库到本地,把之前本地保留的代码push
4、将原来的工程本地的master删除,重新checkout一份到本地,
这样就保留了.idea .iml等配置信息,pom也就不需要再重新导入了。
下面是官方回答:
仓库体积过大,如何减小?
概述
Gitee 平台目前对仓库的配额如下:
套餐 | 免费版 | 基础版 | 标准版 | 高级版 | 尊享版 |
---|---|---|---|---|---|
单仓库 | 最大 500 MB | 最大 1 GB | 最大 1 GB | 最大 2 GB | 最大 3 GB |
单文件 | 最大 50 MB | 最大 100 MB | 最大 100 MB | 最大 200 MB | 最大 300 MB |
如用户在使用过程中不小心将较大的二进制文件加入仓库,那么仓库大小很快就会超过规定的配额,用户可以通过升级到对应的套餐配额或对仓库进行历史改写瘦身,来解除系统对仓库推拉服务的锁定。
- 套餐升级可访问:https://gitee.com/enterprises 了解
- 仓库瘦身方案见下方:
查看存储库中的大文件
git rev-list --objects --all | grep -E `git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print$1}' | sed ':a;N;$!ba;s/\n/|/g'`
或
git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -15 | awk '{print$1}')"
改写历史,去除大文件
注意:下方命令中的
path/to/large/files
是大文件所在的路径,千万不要弄错!
git filter-branch --tree-filter 'rm -f path/to/large/files' --tag-name-filter cat -- --all
git push origin --tags --force
git push origin --all --force
如果在 git filter-branch
操作过程中遇到如下提示,需要在 git filter-branch
后面加上参数 -f
Cannot create a new backup.
A previous backup already exists in refs/original/
Force overwriting the backup with -f
并告知所有组员,push 代码前需要 pull rebase,而不是 merge,否则会从该组员的本地仓库再次引入到远程库中,导致仓库在此被 Gitee 系统屏蔽。
更加具体的操作可以点击文章 改写历史,永久删除git库的物理文件 查看
Gitee 存储库体积控制策略
Gitee 已将服务端的钩子切换到 GNK (Gitee Native Hook),GNK 基于 C++ 编写,使用了 Git 环境隔离等高级特定,意味着大文件检测和存储库体积检测不会再有漏网之鱼。一些用户的存储库体积已经超过了 Gitee 配额限制,而之前的钩子检测存在缺陷,无法实时拦截大存储库和大文件,当切换到 GNK 后,这些用户修改他们的存储库却无法推送到 Gitee,这让他们产生了困扰。
《Gitee 存储库体积控制策略》就这一困扰解答若干问题,详情请见:https://my.oschina.net/GIIoOS/blog/3126211
一些工具
https://github.com/newren/git-filter-repo
https://rtyley.github.io/bfg-repo-cleaner/
https://git-scm.com/docs/git-filter-branch