目录
问题现象：
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 中执行
bash
git verify-pack -v .git/objects/pack/pack-*.idx | sort -k 3 -n | tail -3命令解析：
verify-pack 命令用于显示已打包的内容，我们用它来找到那些大文件。
-v（verbose）参数是打印详细信息。
--objects：列出该提交涉及的所有文件ID
执行结果：
bash
f4bcfa14220885922ca311a9b97ab6a087269057 blob 1194049978 1193418168 7030313773
9e91faabd113ac69a6534c50a8dc3718f556b20c blob 1237993230 1237347387 10317735659
c7d414a597a838e9174fc68ae4fbe78aa8084b91 blob 1237993230 1237347335 9080388324
2.查询大文件的文件名称：
执行命令：
bash
git rev-list --objects --all | grep f4bcfa14220885922ca311a9b97ab6a087269057命令解析：
rev-list 命令用来列出Git仓库中的提交，我们用它来列出所有提交中涉及的文件名及其ID。 该命令可以指定只显示某个引用（或分支）的上下游的提交
--objects：列出该提交涉及的所有文件ID
--all：所有分支的提交，相当于指定了位于 /refs 下的所有引用
执行结果：
bash
f4bcfa14220885922ca311a9b97ab6a087269057 dist-aidmav3.1.5-2020091502.zip
3.将文件从tree中移除
执行命令：
bash
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), 所以我们要用命令彻底清除它, 并收回空间.
执行命令：
bash
$ 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.提交修改远程仓库
执行命令：
bash
git push origin master --force
git remote prune origin参考学习：
git目录下object文件过大清理_git object 特别大-CSDN博客
https://www.cnblogs.com/shines77/p/3460274.html
最后
如果说
友友们之间的点赞
展现的是相互之间的支持，善意和友情
那么
你对我文章的认真阅读
则是对我的劳动成果的
默默地承认和支持
每一次创文的过程
都是我锻炼自己逻辑思维能力和语言组织能力的过程
也是我
不断深悟生活，思考人生的过程
每一篇文章的形成
都是我心血的结晶
能有幸被你阅读