解决GIT单个仓库过大的问题( 拆库 + git子模块 + git lfs + 缩减仓库 ……)

1. 引言

最近在coding上做了一个新项目，一个linux的工控项目，从boot到内核驱动到应用都有要写，所以把这几个部分都扔到一个git仓库里去管了。加上我这人有个坏习惯，喜欢把项目中要用的参考资料和买的模块资料等都扔到Doc文件夹里，很多时候也没有加入忽略列表，提交就一起提交了。
做了没几天，看了一下coding的仓库目录，有点懵，已经用了1G多了。。
其实coding还算好的，至少免费版的单个仓库是2G，码云只有500M。
其实怎么说正常存代码2G妥妥够了，一整个linux源码传上来也就占了不到200m，uboot不到20M(只算源码，不传中间文件)。2G空间还是自己胡乱整废，不过不管怎么样，现在总是要处理这个问题。
想了想，估计也就从这么几个方面入手了。

2. 拆库(多仓库 repo)

拆库其实是一个很好的方法，在划分的同时也同步在做项目的解耦，把不同的内容用不同的仓库来管理，多个git构成了整个项目。
coding现在是支持这种多项目的，单个仓库2G，多个仓库的

但是库多了，就会面临管理的问题，每个库要单独拉，单独推，单独更新，单独管理，很麻烦，其实有一些工具可以帮助我们管理。
比如安卓工程开发使用的repo，可以所有git统一建立分支，统一推送，统一拉取，等等。
（笔者在单位使用的是repo，但是在家不知道怎么搭建repo服务器 T-T，所以采用另外的方法，就是git子模块）
2022.8补记：搭建repo的方法在此.
只需要有一些git仓库就可以搭建，repo本身不需要服务器的特殊协议支持。

3. 拆库 （git子模块）

子模块用起来要简单一些，tortoiseGit自带的菜单里就有。与简单同步的，就是丧失了repo这种统一管理的便捷性。

4. git lfs

这个是在coding的文档里看到的，也是coding推荐的做法。
大文件通过lfs来跟踪，不占用git仓库空间。
目前coding是不对lfs文件做容量限制的。
其实感觉这个做法有点类似于SVN，大文件都是统一上传到一个lfs的服务器，git仓库里管理只是这些文件的指针，因此几乎不占空间，相对的，本地也不再拥有这些文件的完整历史备份，这些备份文件都存在lfs服务器上，这个感觉和git一直以来的本地化，去中心化，有些冲突。
但是想想，其实这些大文件压根也没必要在本地保留若干份完整的版本备份，很少很少会用到。真的是冗余数据。因此lfs的做法也是能接收的，算是吸收了svn的一些优点吧。

5. 缩减仓库(删除大节点)

可以采用类似这个文章这种做法，相当于把一些比较大的节点删除掉。但是操作起来比较复杂，影响git仓库的稳定性。
.git文件过大，github仓库瘦身