目前所在公司开发的系统为一个基础版本（通用版）包含了行业内一些基础功能实现，后期根据不同厂家进行定制版的开发，考虑独立项目的话代码维护不太方便，并且如果通用版本有变动的话，其他定制版本也都需要进行变动。
**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
_注：此方案目前只是一个规划，如果您有更好的方案还请留言告知_
转播
