zoukankan      html  css  js  c++  java
  • 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分支

  • 相关阅读:
    .NET XmlNavigator with Namespace
    编程要素
    【FOJ】1962 新击鼓传花游戏
    【POJ】1389 Area of Simple Polygons
    【POJ】2482 Stars in Your Window
    【HDU】3265 Posters
    【HDU】1199 Color the Ball
    【HDU】3642 Get The Treasury
    【HDU】4027 Can you answer these queries?
    【HDU】1542 Atlantis
  • 原文地址:https://www.cnblogs.com/SimonHu1993/p/15152628.html
Copyright © 2011-2022 走看看