目录
问题现象:
解决办法:
目前实践方法2,步骤如下:
1.识别出最大的三个文件
2.查询大文件的文件名称:
3.将文件从tree中移除
4.清理和回收空间
5.提交修改远程仓库
问题现象:
gitlab项目12G,但实际项目就几百兆,后本地排查,发现pack文件过大,特此记录一下,object文件清理问题。
找了一下原因,.git/objects/pack 文件过大,可能是由于开发过程中上传过大文件,虽然现已删除,但仍然保存着git记录中。
就比如每次npm run build生成dist,需要打包到服务器,这个可能就上传到记录中了。
git项目越来越大的原因:
git add
和git commit
的过程中,保存修改了的文件的blob
,更新索引,创建tree
对象,最后创建commit
对象,这些commit
对象指向了顶层tree
对象以及先前的commit
对象。这三类 Git 对象 ──blob
,tree
以及commit
── 都各自以文件的方式保存在.git/objects
目录下。所以,当你提交了一个体积特别大的文件后,会记录在
objects
文件夹下,删除一个文件,只是记录了删除这个操作,但并不会把文件从.git
文件夹删除。 当你直接从项目中删除该文件,.git
文件夹完全不会变小(理论上还会变大一点,因为多记录了一次删除操作。。。)
解决办法:
1.新建一个只有master分支的当前版本的新项目,原项目做备份或删除;
2.彻底删除历史记录,清理object文件大小。
补充一点, 如果你想以后也不会再上传这个文件或文件夹, 请把这个文件或文件夹添加到.gitignore文件里, 然后再push你的项目
目前实践方法2,步骤如下:
1.识别出最大的三个文件
进入项目根目录,在git bash 中执行
git verify-pack -v .git/objects/pack/pack-*.idx | sort -k 3 -n | tail -3
命令解析:
verify-pack 命令用于显示已打包的内容,我们用它来找到那些大文件。
-v(verbose)参数是打印详细信息。
–objects:列出该提交涉及的所有文件ID
执行结果:
f4bcfa14220885922ca311a9b97ab6a087269057 blob 1194049978 1193418168 7030313773
9e91faabd113ac69a6534c50a8dc3718f556b20c blob 1237993230 1237347387 10317735659
c7d414a597a838e9174fc68ae4fbe78aa8084b91 blob 1237993230 1237347335 9080388324
2.查询大文件的文件名称:
执行命令:
git rev-list --objects --all | grep f4bcfa14220885922ca311a9b97ab6a087269057
命令解析:
rev-list 命令用来列出Git仓库中的提交,我们用它来列出所有提交中涉及的文件名及其ID。 该命令可以指定只显示某个引用(或分支)的上下游的提交
–objects:列出该提交涉及的所有文件ID
–all:所有分支的提交,相当于指定了位于 /refs 下的所有引用
执行结果:
f4bcfa14220885922ca311a9b97ab6a087269057 dist-aidmav3.1.5-2020091502.zip
3.将文件从tree中移除
执行命令:
git filter-branch --index-filter 'git rm --cached --ignore-unmatch dist-aidmav3.1.5-2020091502.zip'
命令解析:
filter-branch命令可以用来重写Git仓库中的提交。
–index-filter参数用来指定一条Bash命令,然后Git会检出(checkout)所有的提交, 执行该命令,然后重新提交。
4.清理和回收空间
虽然上面我们已经删除了文件, 但是我们的repo里面仍然保留了这些objects, 等待垃圾回收(GC), 所以我们要用命令彻底清除它, 并收回空间.
执行命令:
$ rm -rf .git/refs/original/
$ git reflog expire --expire=now --all
$ git gc --prune=now
# Counting objects: 2437, done.
# Delta compression using up to 4 threads.
# Compressing objects: 100% (1378/1378), done.
# Writing objects: 100% (2437/2437), done.
# Total 2437 (delta 1461), reused 1802 (delta 1048)
$ git gc --aggressive --prune=now
# Counting objects: 2437, done.
# Delta compression using up to 4 threads.
# Compressing objects: 100% (2426/2426), done.
# Writing objects: 100% (2437/2437), done.
# Total 2437 (delta 1483), reused 0 (delta 0)
命令解析:
git-reflog 管理reflog信息
--expire=<time> 剪除比指定时间更早的条目。如果未指定此选项,则从配置设置中获取到期时间,而配置设置
gc.reflogExpire
又默认为90天。--expire=all
不论年龄大小,都能修剪;--expire=never
关闭修剪可及条目。expire 命令修剪旧的reflog条目
--all 处理所有引用的reflog
git gc 清理不必要的文件并优化本地存储库
--aggressive 通常
git gc
运行速度很快,同时提供良好的磁盘空间利用率和性能 此选项将导致git gc
更积极地优化存储库,但花费更多时间。这种优化的效果是持久的,所以这个选项只需要偶尔使用。--prune=<date> 修剪比日期更旧的松散对象(默认为2周前,可由配置变量覆盖
gc.pruneExpire
)。--prune =不管年龄大小,都修剪松散的物体,并且如果另一个进程同时写入存储库,则会增加腐败风险; 请参阅下面的“注意事项”。--prune默认打开详细学习《git gc》《git reflog》
现在你再看看你的.git目录文件大小是不是变小了。
5.提交修改远程仓库
执行命令:
git push origin master --force
git remote prune origin
参考学习:
git目录下object文件过大清理_git object 特别大-CSDN博客
彻底删除git中的大文件 - 简书
https://www.cnblogs.com/shines77/p/3460274.html
最后
如果说
友友们之间的点赞
展现的是相互之间的支持,善意和友情
那么
你对我文章的认真阅读
则是对我的劳动成果的
默默地承认和支持
每一次创文的过程
都是我锻炼自己逻辑思维能力和语言组织能力的过程
也是我
不断深悟生活,思考人生的过程
每一篇文章的形成
都是我心血的结晶文章来源:https://www.toymoban.com/news/detail-772834.html
能有幸被你阅读文章来源地址https://www.toymoban.com/news/detail-772834.html
欢迎点赞,评论,互关!~~
到了这里,关于【经验分享】git项目.git/objects/pack很大,clone很久,object文件清理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!