摘要:维护着一个微型的文件系统,其中的文件也被称作数据对象。经过我的验证,确实是这个文件夹中的文件占了磁盘上的空间。与大部分版本控制系统的差别是很大的,比如等等,使用的是增量文件系统就是说它们存储每次提交之间的差异。
最近在开发一个新应用,有一天在gitlab上clone代码的时候发现我的应用竟然有170+M,明明是一个全新的应用,代码都没有几行呢,为什么会有这么大呢?
后来经过了解Git的原理,解决了这个问题,把相关内容记录下来。分享一下。
Why我的一个新应用竟然要170+M,这是打死我我也不会信的,于是就开始分析为什么会这么大。
step 1. 把代码拉到本地git clone git@github.com:hollischuang/Architecture-Evolution.git
只是用这个地址举例,实际并不是这个项目。
step 2. 查看哪个文件占用的空间比较大$cd Architecture-Evolution $du -d 1 -h 174M ./.git 264K ./test 96K .
于是,发现是.git目录自己就占用了174M,了解Git的人都知道,.git目录是git自己生成的,记录了git仓库的相关信息的。看到这里其实并不难知道原因。
Git 维护着一个微型的文件系统,其中的文件也被称作数据对象。所有的数据对象均存储于项目下面的 .git/objects中。
经过我的验证,确实是.git/objects这个文件夹中的文件占了磁盘上174M的空间。
也就是说,只要我有一次将一个大文件误提交了,那么即使我后面把它删除了,但是,实际上在.git中,这个文件还是存在的,虽然我们可能再也不需要他了,但是他还在那里默默的存在着。。。
Git与大部分版本控制系统的差别是很大的,比如Subversion、CVS、Perforce、Mercurial 等等,使用的是“增量文件系统” (Delta Storage systems), 就是说它们存储每次提交(commit)之间的差异。Git正好与之相反,它会把你的每次提交的文件的全部内容(snapshot)都会记录下来。这会是在使用Git时的一个很重要的理念。
也就是说,如果我又一次把一个大文件务提交到git仓库中了,那么,下次提交时,即使你只改动了某个文件的一行内容,Git 也会生成一个全新的对象来存储新的文件内容。
因为以上两个特性,我回想起我的一次手残行为:
刚刚创建一个应用之后,我快速的写完代码,编译,运行,发现没啥问题之后,我准备先把他发布掉,于是我开始创建git仓库,并尝试把代码提交上去,这时我并没有创建.gitignore文件,我直接git add . git commit -m "init" git push一气呵成的执行了熟悉的操作。
相信聪明的人已经发现了,逗比啊,我在编译代码之后,会有很多jar被我down到target目录下。我直接git add.把target下面的jar包,war包等这些也直接提交了。。。虽然后面我意识到,并且删除了这些文件,然后再次提交,但是由于刚我们说过的原因,这些文件依然占用着我的空间。。。
更多关于git的原理内容参见:Git 内部原理
How问题已经定位到了,接下来就是要解决问题了。如果对git的原理及命令了解的比较多的话,这个问题还是比较好解决的,由于当时博主并不十分了解git的原理,所以做了一些知识储备之后才开始动手的。(Git 之术与道 — 对象、为什么你的 Git 仓库变得如此臃肿)
Step 1 查看哪些历史提交过文件占用空间较大使用以下命令可以查看占用空间最多的五个文件:
git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk "{print$1}")"
rev-list命令用来列出Git仓库中的提交,我们用它来列出所有提交中涉及的文件名及其ID。 该命令可以指定只显示某个引用(或分支)的上下游的提交。step 2. 重写commit,删除大文件--objects:列出该提交涉及的所有文件ID。
--all:所有分支的提交,相当于指定了位于/refs下的所有引用。
verify-pack命令用于显示已打包的内容。
使用以下命令,删除历史提交过的大文件:
git filter-branch --force --index-filter "git rm -rf --cached --ignore-unmatch big-file.jar" --prune-empty --tag-name-filter cat -- --all
上面脚本中的big-file.jar请换成你第一步查出的大文件名,或者这里直接写一个目录。
filter-branch命令可以用来重写Git仓库中的提交--index-filter参数用来指定一条Bash命令,然后Git会检出(checkout)所有的提交, 执行该命令,然后重新提交。
–all参数表示我们需要重写所有分支(或引用)。
在重写提交的过程中,会有以下日志输出:
Rewrite 6cdbb293d453ced07e6a07e0aa6e580e6a5538f4 (266/266) # Ref "refs/heads/master" was rewritten
如果显示 xxxxx unchanged, 说明repo里没有找到该文件, 请检查路径和文件名是否正确,重复上面的脚本,把所有你想删除的文件都删掉。
step 3. 推送修改后的repo以强制覆盖的方式推送你的repo, 命令如下:
git push origin master --forcestep 4. 清理和回收空间
虽然上面我们已经删除了文件, 但是我们的repo里面仍然保留了这些objects, 等待垃圾回收(GC), 所以我们要用命令彻底清除它, 并收回空间,命令如下:
rm -rf .git/refs/original/ git reflog expire --expire=now --all git gc --prune=now
至此,我们已经彻底的删除了我们不想要的文件。
原文链接
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/96453.html
摘要:优化空间不大主要关注另外两个上面。目前为止,项目打包后的大部头就是,这个目前的优化空间较小。当然,从整体优化的大维度上来说优化的点还有很多,这个文章继续更新下去。 项目现状 项目是一个数据监测平台,引入了ehcart和three.js 负责项目的数据可视化;打包后,体积高达2.1M,这个体积相比于我的项目规模来说就显得稍有笨重了 使用webpack-bundle-analyzer分析了...
摘要:首发公众号程序员日记作者贤榆的榆如果你觉得有帮助欢迎关注赞赏转发阅读时间字分钟注先简述一下时间线月日周日上午拿到新的下午装好系统晚上从旧的上迁移数据到新。到月号还没有修复,官方也还没有任何关于这方面的恢复。 showImg(https://segmentfault.com/img/remote/1460000016418427?w=690&h=365); 首发公众号:Android程序...
摘要:问题分析随着回滚版本的放量,主端崩溃逐渐回归正常,进一步坐实了新版本存在问题。内容非常多但都是重复的,看起来进程没有启动,导致连接端一直在进行重连。背景公司的主打产品是一款跨平台的 App,我的部门负责为它提供底层的 sdk 用于数据传输,我负责的是 Adnroid 端的 sdk 开发。sdk 并不直接加载在 App 主进程,而是隔离在一个多带带进程中,然后两个进程通过 tcp 连接进行通信...
阅读 2775·2023-04-25 23:08
阅读 1565·2021-11-23 09:51
阅读 1542·2021-10-27 14:18
阅读 3103·2019-08-29 13:25
阅读 2806·2019-08-29 13:14
阅读 2860·2019-08-26 18:36
阅读 2182·2019-08-26 12:11
阅读 793·2019-08-26 11:29