git submodule使用场景

使用场景

耗费一年心血的项目上线已经有了一段时间,觉得可以喘口气了,这个时候领导下达命令,需要开发B项目了,但是B项目有这样一个特征,就是跟A特别像,这个像是从功能、展现形式等等都很像,领导希望能够快速开发出来,基于此,我就需要考虑如何能够解决这个架子改造及实现最大程度的code复用问题。
我参与的项目整体技术架子如下:
Angular(frontend)-----------------node-express(backend)
当时咨询了很多的人,自己也想过,因为公司项目本身是在gitlab上管理的,所以随之有以下三个方案:

  1. 一个仓库下,直接各个项目的都存在,仅仅是文件夹层面的区分,通过参数来控制
  2. 分支化处理,比如branch-project-a,branch-project-b
  3. 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中遇到如上场景的,建议使用这种机制吧。

Donate comment here