随笔- 24  评论- 4  文章- 0 

git程序多版本维护方案

目前所在公司开发的系统为一个基础版本(通用版)包含了行业内一些基础功能实现,后期根据不同厂家进行定制版的开发,考虑独立项目的话代码维护不太方便,并且如果通用版本有变动的话,其他定制版本也都需要进行变动。

**gitflow工作流**

公司之前采用svn进行维护代码,最近才开始进行转变到用git 进行维护,在学习的过程中对比了一番最终选择采用gitflow工作流进行管控,
具体介绍如下:



**master分支**:主分支,可随时交付给用户使用的版本

**dev分支**:开发分支,项目组内用于开发的分支,并且保证该分支代码是可运行

**feature分支**:功能分支,项目中开发新需求或者修改bug都在此分支上进行。

**release分支**:测试分支,开发完成之后,基于dev创建该分支

**hotfix分支**:bug修复分支,用于修复bug,发现bug创建此分支进行修复,基于release或者master分支创建

由于现在处于开发阶段故现在对分支的维护方面没有那么完善,而且公司内部没有测试人员,现在的测试流程都是写完代码内部自己进行测试,现在进行开发的时候一般都是基于dev分支创建feature分支:


**创建feature分支以及合并方案**

* 当前处于dev分支或者release分支,基于dev或者release创建新分支

* 创建新功能分支并且切换到该分支,当该功能开发完毕之后,如果该功能开发周期较长,每天从dev分支合并到功能分支上,避免跟dev分支差异较大
* 当功能开发完成合并到dev或者release分支当中,完成之后删除本地分支,避免本地分支过多,分不清功能是否合并。

**创建release分支以及合并方案**

* 当前处于dev分支当中,基于dev分支创建release分支
* 创建该分支之后,进行打包发布测试,如果测试当中发现bug,创建hotfix分支,进行修复bug,创建hotfix分支主要想的是多人开发过程中,发现那个模块谁负责,谁去修改bug
* 当该分支测试完成之后合并到master和dev分支当中

**创建hotfix分支以及合并方案**
* 当前处于release分支或者master分支当中
* 当release分支发现bug之后,根据release分支创建该分支,进行修复bug。
* 该分支修改完成之后如果是release的bug合并到release分支就可,如果是基于master分支创建的还需要合并到dev分支当中


**命名规则**

分支命名方式采用如下规则
例如: add_user_20180302
add:代表工作类型user代表具体功能模块:
user:具体的功能模块
20180302:分支创建时间


**git注释提交规范**

注释提交采用如下规则
例如:[修复bug]:bug号
1.修复的具体功能

****

基于上述规范根据我们项目组的情况,创建了如下三个版本的分支结构如下:

* master分支
* master-A分支
* master-B分支

**master分支**

基础版本分支,开发一些通用功能(目前所有工作都是在此版本开发)

**master-A分支**

基于通用版本生成的一个分支版本,根据A客户提出的新需求进行客制化的开发

**master-B分支**

基于通用版本生成的分支版本,根据B客户提出的新需求进行客制化开发

**master分支维护**

master版本维护分如以下:
dev
release/
hotfix/
feature/


**master-A/master-B维护**

master-A或者master-B版本维护分支如下:
dev-A
release-A/
hotfix-A/
feature-A/


**基础版本同步方案**

当基础版本有新功能开发,或者是修复之前遗留的bug,开发完成之后,合并到其他master-A或者master-B分支当中,避免重复开发带来的时间成本。

**开发注意事项**

根据不同的业务创建分支的时候选择创建不同的分支,例如master分支在进行创建功能分支的时候应该是:

* feature/add_user_0302

master-A创建功能分支应该是:
* feature-A/add_user_0302

_注:此方案目前只是一个规划,如果您有更好的方案还请留言告知_

posted on 2019-04-22 08:53 zyz1 阅读(...) 评论(...) 编辑 收藏