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分支**

基础版本分支，开发一些通用功能（目前全部工做都是在此版本开发）

**master分支维护**

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

 

**开发注意事项**

根据不一样的业务建立分支的时候选择建立不一样的分支，例如master分支在进行建立功能分支的时候应该是：

* feature/add_user_0302

_注：若是您有更好的方案还请留言告知_