• 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

    代码提交示例

    角色及职责定义

    模块的开发组员: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分支;
    正常开发常规版本流程

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

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


    注意事项

    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分支

  • 相关阅读:
    Android中Handler原理
    微软柯塔娜(Cortana)的一句名言
    C# 单例模式的五种写法
    HTTP Status 404
    PLSQL中显示Cursor、隐示Cursor、动态Ref Cursor差别
    Android 开发之集成百度地图的定位与地图展示
    iOS知识点汇总
    优化报表系统结构之报表server计算
    淘宝中间的一像素线(手机端)
    解决yum升级的问题“There was a problem importing one of the Python modules”
  • 原文地址:https://www.cnblogs.com/SimonHu1993/p/15152628.html
Copyright © 2020-2023  润新知