git submodule使用场景
使用场景
耗费一年心血的项目上线已经有了一段时间，觉得可以喘口气了，这个时候领导下达命令，需要开发B项目了，但是B项目有这样一个特征，就是跟A特别像，这个像是从功能、展现形式等等都很像，领导希望能够快速开发出来，基于此，我就需要考虑如何能够解决这个架子改造及实现最大程度的code复用问题。
我参与的项目整体技术架子如下:Angular(frontend)-----------------node-express(backend)
当时咨询了很多的人，自己也想过，因为公司项目本身是在gitlab上管理的，所以随之有以下三个方案:
- 一个仓库下，直接各个项目的都存在，仅仅是文件夹层面的区分,通过参数来控制
- 分支化处理，比如branch-project-a,branch-project-b
- git-submodule
方案对比
对比这三个方案,分析:
方案1肯定是直接否掉，因为这样子维护性就低的要死，仅仅是dev短期方便，但是人工造成错误的可能性及维护性都低，方案2，可以，但是这样就意味着多个项目是在一个仓库下进行dev和管理，那么换句话说这个developer的人就具有轻易的动多个项目的可能性，我认为这样子是很可怕的，另外，项目A与项目B的差异性开发就会导致未来分支数目众多，维护合并都不够清晰，简单，毕竟本来就不是一个项目，只是相似，仅此而已，so我认为方案2也应该杀掉。
方案3，git子模块方案相当于将部分code抽离成独立的一个仓库，然后利用git的子模块机制进行映射引入，然后本身子模块也是个仓库就可以独立开发维护，项目中引入后，只管像用第三方包的方式一样去使用即可。
思来想去，我认为方案最终要体现两点:项目A与项目B是两个相同，就决定了必须是独立的存在；项目A与项目B有相同点，决定了有一定的复用，所以基于此，确定选方案3
使用感受
git子模块的使用就类似于我们node开发，使用npm管理所有的第三方类包一样，只管去用，但不要试图直接去改，因为你只是使用方。git子模块的引入使用也是倒逼着将项目中的代码，进行一定程度的抽离抽象，能够适应更多的情况，这样对于代码的质量、灵活性、乃至开发人员本身的技能认识，都会有不少的帮助。所以建议那些在实际dev中遇到如上场景的，建议使用这种机制吧。