Git版本管理流程与规范-生活圈

分支定义及含义说明
分支流程中包含5类分支,分别是master、release、test、dev、hotfix,各类分支作用和生命周期各不相同。

【master 】:(仅一个)该分支是线上稳定版本代码,禁止提交代码;对于各种库的依赖都需要依赖此分支,需求上线时从dev分支直接合并到master分支;
【dev 】:开发分支(有多个),从master分支切出,是需要开发代码的分支,所有开发均在dev分支;
【test 】:测试分支(仅一个),首次从master切出,需求提测时从dev分支合并到test分支进行测试;
【release】:预发布分支(仅一个),首次从master分支切出,需求上线前从dev合并到release分支,部署到预发布环境,进行上线前测试(暂时缺少此环境,预留此分支);
【hotfix 】:有多个,从master分支切出,解决线上紧急BUG的修复。

分支命名规则
dev开发分支命名规则:
基础分支可以命名为:dev
迭代需求的支命名方式:dev-${APP版本号},如:dev-803(表示:APP的8.03版本);
正常需求分支命名方式:dev-${需求名},如:dev-life(生活号需求)、dev-ux(UX迭代需求)
hotfix分支命名规则:
hotfix-${日期},如:hotfix-20210813

代码提交示例
Git版本管理流程与规范-生活圈

角色及职责定义

模块的开发组员:maintainer
dev、hotfix的分支开发
模块的开发负责人(组长/模块负责人):Owner
从master 打 dev、test、release、hotfix 分支
dev、hotfix的分支开发
从dev分支合并到test
从dev分支合并到master
将master合并到各个dev分支
删除hotfix分支
分支记录存放位置 - Git->wikis->分支记录

版本号规范
dev、test及release版本号命名规则 - <主版本号>.<副版本号>.<发布号>
主版本号设置规则
产品的主体构件进行重大修改,主版本号加1
产品的主体构件之间的接口协议重大修改,主版本号加1
副版本号设置规则
主版本号变更时,副版本号置0
数据结构变更(新增或修改注释含义的情况除外),副版本号加1
若副版本号累加至超过90时,采用主版本号进位制,主版本号加1,副版本号重新置0
发布号设置规则
主版本号或副版本号变更时,发布号置0
若发布的版本无数据结构变更,则发布号加1

hotfix版本号命名规则 - <主版本号>.<副版本号>.<发布号>
hotfix由于即修即删,因此同release版本的版本号即可
说明:主版本号和副版本号的变更标志着重要的功能或结构变动。发布号的变更,用于体现小的功能变更

各种场景流程规则

当需要开发常规迭代时:
从master分支创建dev分支,例如:dev1.3.0;
在dev分支上开发代码,push到远程仓库;
dev分支代码开发完毕,合并到release分支,例如:release1.3.0 <开发组长/模块owner>;
测试人员在release1.3.0分支进行测试,测试完毕后拿release1.3.0分支部署;
上线验收完毕后将release1.3.0分支合并到master分支;
正常开发常规版本流程
Git版本管理流程与规范-生活圈

紧急&BUG修复版本流程规则

当需要修复线上紧急BUG时:
从master分支创建hotfix分支;
在hotfix分支修复BUG,push到远程仓库;
BUG修复完毕后,合并到test测试分支进行测试,例如:hotfix-20210813合并到test分支 <开发组长/模块owner>;
测试人员在test分支进行测试,测试完毕后拿hotfix分支合并到master进行部署;
上线验收完毕后将master分支合并到各个dev分支;
当需要修复线上紧急BUG流程图:

Git版本管理流程与规范-生活圈
注意事项

dev分支之间不能合并代码
release分支不能合并到dev分支
从dev分支合并到test分支测试时,只能合并dev分支上自己的commit到test,可参考git cherry-pick、git rebase命令
如发现当前test分支测试时,落后于master一个版本及以上,需要将master合并至当前test分支;
严禁直接在test、release、master分支进行需求开发和修改bug,特殊情况除外;
只有需求到提测日期才需要把开发分支的代码合并到测试分支test上;
需求提测后如需要修改bug,在原来的dev分支修改,然后合并到test分支进行测试;

相关环境
预发布环境
生产环境
开发环境
测试环境

举例说明(以803版本需求为例)

web-api 和 lib-service 项目现基于master分支创建了 test分支和dev-803分支,

test分支:测试分支,替换现有的testenv分支,

dev-803分支:803版本的需求开发的代码提交到此分支;

开发阶段把代码提交到dev-803分支,在本地开发联调通过后 并到达提测日期时再合并到test分支上;未到提测日期请不要合并到test分支;

803版本测试阶段,修改bug还是在dev-803分支提交,然后再合并到test分支进行测试;

当803版本达到上线标准时,直接把dev-803分支合并到master分支

Git版本管理流程与规范-生活圈

上一篇:vs 2019使用码云 gitee


下一篇:Ansible Jinja2 模板