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