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

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_0302add：代表工作类型user代表具体功能模块：user:具体的功能模块0302:分支创建时间
复制代码

git注释提交规范

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

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

• master分支
• master-A分支
• master-B分支

master分支

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

master-A分支

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

master-B分支

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

master分支维护

    master版本维护分如以下：devrelease/hotfix/feature/
复制代码

master-A/master-B维护

    master-A或者master-B版本维护分支如下：dev-Arelease-A/hotfix-A/feature-A/
复制代码

基础版本同步方案

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

开发注意事项

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

• feature/add_user_0302

master-A创建功能分支应该是：

• feature-A/add_user_0302

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