权益领取git代码分支管理规范

开发分支

发布5.1.38版本合并稳定代码到master分支同步到dev分支

远端分支remote repository

版本迭代分支：迭代版本发布和发布过程bug修改

feature01_分支

bug修复完成

dev

修复bug分支 hotfix

正常规划版本

迭代38开始

迭代40开始

分支命名规则>补丁命名：版本名+SP+禅道编号（或日期）；例如：CMJY1022SP1028>release命名：版本号。例：CMJY1022>feature命名：CMJY1022 + CD+需求编号>hotfix命名：hotfix+补丁bug编号

迭代39开始

发版测试

Tag5.1.38

需求1场景

迭代39发布完成

紧急bug

master

feature03_分支

需求3场景

迭代开发完成

稳定版本

完成发版(Tag)

修复bug分支hotfix

本地分支local repository

开始迭代39发布

主开发分支develop

主开发分支 dev

需求2场景

主分支 master

生产线上出现bug

代码管理后台：GitLab1、主分支：master，稳定版本代码分支，对外可以随时编译发布的分支，不允许直接Push代码，只能请求合并（pull request），且只接受feature、hotfix、冲刺分支的代码合并。gitlab上做限制。2、热修复分支：hotfix，针对现场紧急问题、bug修复的代码分支，修复完后合并到主分支、开发分支。3、发版分支：release，版本发布分支，用于迭代版本发布。迭代完成后，合并dev代码到release，在release分支上编译发布版本，以及修改bug（定时同步bug修改到dev分支）。测试完成后此版本稳定的代码push到master分支，并打上版本标签。。4、开发分支：develop，开发版本分支，针对迭代任务开发的分支，日常开发原则上都在此分支上面，迭代完成后合并到冲刺分支。5、其他开发分支：develop-***，开发人员可以针对模块自己创建本地分支，开发完成后合并到dev开发分支，然后删除本地分支。

创建分支

Tag5.1.37.1

迭代39结束

分支合并

合并dev分支

release

>开始版本5.1.38发版（合并代码，编译测试版本）>之后这个分支演进，只能是修复该版本的问题>定期同步到dev分支>版本结束分支弃用

分支 release

hotfix

生产环境BUG修复，分别合并到开发分支和主分支

合并分支

本地与远端分支配置：

主分支master

master分支禁止提交代码，只能在gitlab申请合并

紧急需求开发分支feature

marge分支

开发人员可以基于安排的开发功能建立功能开发分支

生产发版

迭代任务开发

merge测试验证

Tag5.1.39

最终功能分支需要合并到开发分支并删除

feature02_分支

迭代38结束

权益领取git代码分支管理

freature

master打tar

版本测试发布分支release

创建分支开发

时间趋势

紧急需求规划

Tag5.1.37