Git 仓库过大问题分析处理

背景

近期需要对一个项目进行一些小更改,仓库本身是很小的,但是在 git clone 项目的时候却等待了很久。如图:

不禁产生了疑惑,10M体积左右的仓库为何会产生200多M的数据?

原因分析

通过执行命令 du -d 1 -h 可以分析出当前项目各个文件的体积:

可以看出是 .git 文件占了主要的占比,进入目录详情查找发现,是有一个 .pack 文件特别大。

通过查找相关资料发现:

  • 当使用 git addgit commit 命令的过程中,Git 不知不觉就会创建出来 blob 文件对象,然后更新 index 索引,再然后创建 tree 对象,最后创建出 commit 对象,这些 commit 对象指向顶层 tree 对象以及先前的 commit 对象。
  • 而上述创建出来的对象,都以文件的方式保存在 .git/objects 目录下。所以,当在使用的过程中,提交了一个体积特别大的文件,就会被 Git 追踪记录在 .git/objects 文件夹下面。
  • 此时,如果再次删除这个体积特别大的文件,其实 Git 只会记录我们删除的这个操作,但并不会把文件从 .git 文件夹下面真正的删除,即 .git 文件夹完全不会变小。

解决方案

  1. 识别出体积最大的几个文件(demo数量为5)
shell 复制代码
git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')"

我们发现基本都是些字体、图片等静态文件。可以和当前目录文件进行对比,看哪些是已经废弃的,可以进行删除操作。

  1. 将该文件从历史记录的所有 tree 中移除
shell 复制代码
git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch 你的大文件名' --prune-empty --tag-name-filter cat -- --all

public/font/PingFangSC-Regular.otf 为例,删除前后对比如下:

  1. 重复2的操作即可,确保删除的文件是已失效
  2. 提交修改
shell 复制代码
# 真正删除
rm -rf .git/refs/original/
git reflog expire --expire=now --all
# 清理无效文件
git gc --prune=now 
git gc --aggressive --prune=now
git push --force

# 让远程仓库变小
git remote prune origin

总结

避免项目中直接存放大文件,使用对象存储/CDN的方式引用这些静态文件。

相关推荐
mCell1 天前
GSAP ScrollTrigger 详解
前端·javascript·动效
gnip1 天前
Node.js 子进程:child_process
前端·javascript
excel1 天前
为什么在 Three.js 中平面能产生“起伏效果”?
前端
excel1 天前
Node.js 断言与测试框架示例对比
前端
天蓝色的鱼鱼1 天前
前端开发者的组件设计之痛:为什么我的组件总是难以维护?
前端·react.js
codingandsleeping1 天前
使用orval自动拉取swagger文档并生成ts接口
前端·javascript
石金龙1 天前
[译] Composition in CSS
前端·css
白水清风1 天前
微前端学习记录(qiankun、wujie、micro-app)
前端·javascript·前端工程化
Ticnix1 天前
函数封装实现Echarts多表渲染/叠加渲染
前端·echarts
用户22152044278001 天前
new、原型和原型链浅析
前端·javascript