git抽离与瘦身场景-抽离子项目以及删除git中无用的大文件

目录

1. 抽离场景---从大项目中抽离一个独立文件夹作为新的子项目

0. 查看git大小

1. 查看有哪些大文件（top 10）

2.在总项目之外任一地方创建一个空项目，并通过本地项目进行动态拉取项目

3.查看新项目目录大小

2.瘦身场景--独立项目删减大文件（夹）场景

0. 查看git大小

1. 查看有哪些大文件（top 10）

2. git filter-branch

3. “遍”操作第一步和第二步

4. 删除缓存下来的ref和git操作记录

5. 垃圾回收

6. 查看git是否减少

7. 把.git里面的修改推上去

---

推荐阅读：为什么你的 Git 仓库变得如此臃肿

可能在小白刚刚接触git的时候，只是掌握了简答的commit pull push clone等等的基本操作，在还没有接触.gitignore的时候，有时候会把一些大文件直接怼到git本地仓库中，殊不知当时间一长久，git的项目就会逐渐变得庞大，那是一个多么痛的领悟啊！！因此一定要摒弃杜绝这种养疽成患的习惯。

接下来就是根据自己平时的经验总结如下几个操作方法，对各个操作做了一次整合与记录。实际的需求本人暂时分为两种。（还有哪些场景，还望各位大佬不吝赐教）

1. 抽离场景---从大项目中抽离一个独立文件夹作为新的子项目

2. 瘦身场景---独立项目删除大文件（file）/ 大文件夹（dir）

1. 抽离场景---从大项目中抽离一个独立文件夹作为新的子项目

此场景是因为实际工作就是在一个项目中又有很多项目，混合开发，比如期初项目是一个javaweb项目，然而随着业务发展，项目的开发模式开始走向前后端分离，那么此时一些前端项目由react/vue/angular编写，而所有后端业务逻辑由java承接，那么有时候我们想在项目实际开发完成之后，剥离前端项目，（假设前端项目所有代码放置于一个单独文件夹下，或者通过重新组件一个文件夹，把这些项目放置于一个新文件夹中），那么我们想把这个项目单独抽离出来形成一个独立的项目来进行单独开发与维护，那么我们怎么操作。

闲话少说，show me the code。

我简单分为5步骤，

0. 查看git大小

$ git count-objects -v

count: 658

size: 13177

in-pack: 24533

packs: 4

size-pack: 5747555

prune-packable: 0

garbage: 0

size-garbage: 0

size-pack 为 实际项目的大小以kb为单位， 这里5G大小，卧槽，这个就是一个超级大炸弹呢不是。要是在这5G文件大小中把除去只留下几M大小的小项目，那无疑是大海捞针，太坑了。不过git给我们一个新功能，就是可以根据某个子目录，并把子目录相关的所有commit信息也一并抽取出来生成一个新分支，这个命令就是subtree命令

1. 查看有哪些大文件（top 10）

$ git subtree split -P ideaproject/reactapp_3d -b eapcubeweb

 ideaproject/reactapp 目录存储的是一个以react开发的web项目 -P <=> -Project（项目的意思）

eapcubeweb 是分支名， -b <=> -branch (分支的意思)

此时我们可以通过

$ git branch

* master

  eapcubeweb

看到有一个eapcubeweb 分支被创建

2.在总项目之外任一地方创建一个空项目，并通过本地项目进行动态拉取项目

mkdir ../eapcubeweb 创建一个目录

cd ../eapcubeweb 进入目录

git init 初始化git项目

git pull ../顶级项目目录 eapcubeweb  从本地git项目中拉取项目以及对应的分支，此时只会拉取相关的refs

3.查看新项目目录大小

$ git count-objects -v

count: 6

size: 1

in-pack: 2937

packs: 1

size-pack: 143318

prune-packable: 0

garbage: 0

size-garbage: 0

可以发现，我们从5G大小的大饼中，切了一小块口子出来，生成了一个独立的新项目，项目大小为143M，对于一个项目来说143M显然还是很大的，但是总比5G小太多了。我们如何进行更进一步地减少体积呢？那就是下面的将要将的瘦身活动了。

2.瘦身场景--独立项目删减大文件（夹）场景

此场景是因为实际工作中会不自觉地将一些大文件或者一些敏感信息不小心直接commit到本地，后续又没有做reset等操作（可能还不太清楚这个东西），因此大伙儿得过且过，就将就着用。那是又非常大的潜在风险的。尤其是一些敏感信息，让我想到了bilibli泄漏事件，除去推广成分，敏感信息往往是大家非常关注的，一旦不小心把敏感信息发布出去，即使后期以commit重新修改方式，在有心人眼里，还是能够把“历史”给扒出来看的。

闲话少说，show me the code。

我简单分为7步骤，

0. 查看git大小

$ git count-objects -v

count: 6

size: 1

in-pack: 2937

packs: 1

size-pack: 143318

prune-packable: 0

garbage: 0

size-garbage: 0

size-pack 为 实际项目的大小以kb为单位， 这里143M大小

1. 查看有哪些大文件（top 10）

git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print$1}')"

命令可以分为如下两步骤理解

1.1 查看有哪些大文件（top 10）

这个命令只能查看对应文件名hash值对应的文件类型以及文件大小，第三列单位为字节(bytes)，如下可以看到有一个非常大的文件，大致有130M左右

$ git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10

339bc58c7c3297d62cb8e5f2adb3411d44faa9c9 blob   901183 245971 14860559

f6e40f652575246527301158499a994d8c0da2b1 blob   901308 246024 4172051

a7e358eee7ec445f98be7e0643bdd897f048dfc8 blob   952135 112106 1942204

155d47e5efca426f4acfff12a69c587d8af590f0 blob   972382 373102 150876

85254d05a2e81de8a84c699dcf9005c964cc0688 blob   3586927 1049913 6310668

edaf3cc9e3b69918c145d6fe5bb1380d8aeeb943 blob   3831516 1613712 16797794 1 3d439f7ae0fd35157badef64a99e98f7e05c58ee

9e31acb78b79e0bb9c04c368da67ea0bcb4a04f2 blob   6637186 1303181 15106530

22a4a4234b6f41738ef4f7230c2786367b1efd2a blob   6637343 1303217 4418075

3d439f7ae0fd35157badef64a99e98f7e05c58ee blob   23890168 5321790 7360581

d2fdda3d1492d397b53a11055dfb87c093950c57 blob   134474097 127995889 18592453

1.2 查看有大文件对应的文件名（top 10）

我们需要知道对应的文件名，方便我们删除文件

$ git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print$1}')"

155d47e5efca426f4acfff12a69c587d8af590f0 dist/js/echarts-all.js

a7e358eee7ec445f98be7e0643bdd897f048dfc8 undefined/css/main.86013fab.css.map

f6e40f652575246527301158499a994d8c0da2b1 undefined/js/34.ae2e8c03.chunk.js

22a4a4234b6f41738ef4f7230c2786367b1efd2a undefined/js/34.ae2e8c03.chunk.js.map

85254d05a2e81de8a84c699dcf9005c964cc0688 undefined/js/main.1599a4ca.js

3d439f7ae0fd35157badef64a99e98f7e05c58ee undefined/js/main.1599a4ca.js.map

339bc58c7c3297d62cb8e5f2adb3411d44faa9c9 dist/js/34.addd526f.chunk.js

9e31acb78b79e0bb9c04c368da67ea0bcb4a04f2 dist/js/34.addd526f.chunk.js.map

edaf3cc9e3b69918c145d6fe5bb1380d8aeeb943 dist/js/main.a2f9ed0b.js.map

d2fdda3d1492d397b53a11055dfb87c093950c57 node_modules.rar

2. git filter-branch

2.1  删除大文件（file）

$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch node_modules.rar' --prune-empty --tag-name-filter cat -- --all

git filter-branch --index-filter 让每个提交的文件都复制到索引(.git/index)中

然后运行过滤器命令：git rm --cached --ignore-unmatch 文件名 ，让每个提交都删除掉“文件名”文件

然后--prune-empty 把空的提交“修剪”掉

然后--tag-name-filter cat 把每个tag保持原名字，指向修改后的对应提交

最后-- --all 将所有ref（包括branch、tag）都执行上面的重写

2.2  删除大文件夹（dir）

删除大文件夹下的所有内容，不用一个一个删，提高删除效率，比如实际应用中基于nodejs开发的前端项目，往往会在npm install安装阶段生成一个node_modules目录，这里是存储当前项目关联的包，可想而知，这个文件有多大，所以我们打算删除以及在之前版本中加入到项目中的该文件夹下面的目录，而且我们确信，删除这个文件夹项目下所有文件对项目本身没有任何关系，所以可以执行下面命令:

$ git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch node_modules' --prune-empty --tag-name-filter cat -- --all

跟删除大文件类似，我们需要添加-rf 递归循环删除文件夹下的所有文件

3. “遍”操作第一步和第二步

重复第一步和第二步，直到自己认为没有垃圾文件为止，这里同比与编译原理的“遍”的概念。

4. 删除缓存下来的ref和git操作记录

$ git for-each-ref --format='delete %(refname)' refs/original | git update-ref --stdin

$ git reflog expire --expire=now --all

与下方两句一致

$ rm -rf .git/refs/original/

$ rm -rf .git/logs

这一步类似于jvm虚拟机中的删除gcroot引用操作，也就是要把所有指向这个文件或目录的记录的引用都删除了，方便垃圾回收机制处理垃圾。

5. 垃圾回收

上面2步把大文件的索引都切断了，这个时候进行垃圾回收，就可以很明显看到效果了 回收操作，.git目录中的文件大小会立马减少（git gc 并不会立马看到 --prune意味着剪枝操作，也就是在在整个构造树中减少所有文件）

$ git gc --prune=now           (立竿见影)

$ git gc           (暗流涌动)

6. 查看git是否减少

$ git count-objects -v

count: 0

size: 0

in-pack: 2752

packs: 1

size-pack: 2166

prune-packable: 0

garbage: 0

size-garbage: 0

经过上方一顿猛如虎的操作，我们看到size-pack减少到了2m，还是略有兴奋的感觉。

7. 把.git里面的修改推上去

这个时候普通的push是不行的，需要强推

git push --force

关于git push 出现无法提交的问题，可以通过

https://blog.csdn.net/yeshennet/article/details/77177522

来查看相关的信息