git submodule使用场景
发表于
更新于
本文字数:
944
阅读时长 ≈
2 分钟
本文是作者对git submodule使用场景的介绍,包括git submodule使用场景的优势、实现细节、相关资料等,这些步骤可以帮助作者提高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
travis-ci自动部署化blog
发表于
更新于
本文字数:
429
阅读时长 ≈
1 分钟
本文是作者对travis-ci自动部署化blog的介绍,包括travis-ci自动部署化blog的优势、实现细节、相关资料等,这些步骤可以帮助作者提高travis-ci自动部署化blog的效率。
利用Cordova将移动站点打包
发表于
更新于
本文字数:
1.6k
阅读时长 ≈
3 分钟
本文介绍关于利用Cordova将移动站点打包,包括使用场景、实现细节等,以提高关于利用Cordova将移动站点打包的效率。
Cordova是什么
发表于
更新于
本文字数:
516
阅读时长 ≈
1 分钟
本文是作者对Cordova是什么的介绍,包括Cordova是什么的优势、实现细节、相关资料等,这些步骤可以帮助作者提高Cordova是什么的效率。