当前位置:   article > 正文

git分支管理规范整理_git 分支管理规范

git 分支管理规范

背景:为了更好长期维护项目开发,保持良好的代码提交记录以及 git 分支结构清晰,因此整理:git分支管理规范。

规范只是提供一定的参考及约束,遇到特殊场景,只需朝着利于长期维护管理的方向处理即可;

一、相关术语

为了先了解开发中常用到或者听到的术语,有利于更好里的理解后面的分支管理

简称全称文字描述使用对象用于变动
devDevelopment Environment持续集成开发环境研发人员开发环境:单元测试,UI测试验证,前后端接口业务逻辑联调测试;
仅供内部人员访问;
最大
testTest Environment测试环境测试人员测试环境:需求业务逻辑集、UI测试,需求涉及功能点回归测试;
仅供内部人员访问;
较大
intIntegration Test Environment集成环境产品各系统集成环境:对接的各系统集成之后最终环境,按照需求进行验证测试;
uatUser Acceptance Test Environment用户验收环境客户方用户体验环境:按照需求功能文档进行验收;
产品、用户(客户方)直接参与测试
较稳定
proProduction Environment生产环境真实客户生产环境:根据实际业务需求使用,解决问题;
真实客户直接使用
稳定

二、分支管理

根据上面的环境术语,可得出不同的环境对应不同的分支命名规则,为了更好缺粉代码功能所属的环境,并且可以更好的解决针对不同环境,解决对应环境的问题,而不需要花费额外的时间寻找版本,commitId等信息;

分支名称对应环境
dev需求开发分支dev
hotfix线上问题紧急修复分支dev、test、int、uat、pro
test测试验证分支test、int
release测试发布,预投入生产分支uat
master生产分支(主分支)pro
  1. master分支
    项目初始化之后,便需要创建 master 分支,如果项目对应多个产品的话,请根据产品信息建立对应的产品主分支如:productA_master;其他场景下,该分支的代码主要是由 release 分支 或者是 hotfix 分支合并,该分支不允许直接修改代码;

  2. dev分支

    根据需求定义dev分之,实现需求业务逻辑;当需求版本投入生产稳定之后,即可删除;命名规范:productA_dev_{版本号}_分支特征_年(两位即可)月日,如:{productA}_dev_v2.0.0_broadcast_240130(2.0.0版本中的播报方式);

  3. test分支

    • dev分支开发完成并进行基本的集成测试,需求实现并测试通过之后,将dev分支的代码进行合并到test分支,供测试人员进行测试验证;测试人员提出的BUG,先在dev分支上修改验证通过之后,合并到test分支,测试人员在进行复测;
    • 测试人员整体测试验证通过,可将test分支提供给int环境,进行集成,产品人员进行测试验证,提出新的BUG,先在dev分支上修改验证通过之后,在此合并到test分支;命名规范: {productA}_test
  4. release分支

    • 当产品人员对集成环境测试验证通过之后,便可将test分支合并到release分支,此时uat环境对应的客户方便可介入测试验证,进行模拟生产实际业务,测试验收;若发现问题查实是BUG,研发人员在dev分支解决并回到第3节点test分支重新执行;
    • 当客户方介入验收成功之后,便可投入生产,若生产环境实际业务需求成功实现,便可将release分支代码进行合并到master分支;
  5. hotfix分支

    • 该分支比较特殊,如果在生产环境出现紧急问题需要修复,研发人员需要基于master分支新建一个hotfix分支,解决生产紧急问题,然后直接将该分支提供给测试人员在test环境验证;int环境产品人员也同时进行测试验证;当前面两者环境验证没有问题,最终在uat环境验证测试通过之后,便可发布到生产环境;
    • 中间环节如果出现问题直接在hotfix分支上面修改;
    • 当分支成功投入生产之后,便可该分支合并进master,然后创建tag并删除该分支;

三、开发场景

3.1 新需求加入

加入有一个用户管理的新需求需要开发,分支命名可以是:dev_v2.1.0_userManager_240130 分支,基于哪一个分支需要根据不同场景进行判断:

  1. 如果 存在未测试完毕 需求:
    • 新需求和未测试完毕的需求一同发布,则基于dev分支创建本次需求分支,最终该分支合并到未测试完毕的分支上;
    • 新需求和未测试完毕的需求不确定是否一同发布,则基于主分支master 分支进行创建,最终该版本和未测试完毕需求哪一个先上线,另一个则需要合并先上线的需求分支代码;
  2. 如果不存在未测试完毕的需求:则直接基于master分支进行本次需求分支;

当本次需求分支开发完毕,并自行验证通过之后,便可准备提测(将需求功能、分支信息、commitId等信息提供给测试人员进行验证);

  1. 将dev需求分支代码合并到test分支(test环境)上;
  2. 测试人员在 testtest环境) 测试通过后, 测试人员将包提供给支撑人员部署到int环境(集成环境),产品人员进行测试验收;
  3. 当产品人员在testint环境)测试验收通过之后,运维人员便可将包部署到uat环境(用户验收环境)供用户跑模拟实际业务的测试流程,同时研发人员将代码合并到 release用户验收环境);
  4. 客户方在 release用户验收环境)测试通过后,运维人员便可着手准备投入pro生产环境),进行升级发布;
  5. 当需求成功上线之后,便可基于 dev_v2.1.0_userManager_240130 创建一个tag,描述具体的功能点,然后dev_v2.1.0_userManager_240130 分支便可删除;

3.2 普通迭代

有一个用户管理的迭代需求,如果开发工时 < 1人/天(一个人开发一天),直接在 dev_v2.1.0_userManager_240131 开发,如果开发工时 > 1人/天(一个人开发一天),那就创建分支新的分支dev_v2.1.0_userManagerIterate_240131,在新分支上开发并进行测试验证通过之后,在合并到test分支。

注:开发后的提测上线流程 与( 3.1) 章节新需求加入的流程一致。

3.3 修复测试和集成环境 Bug

测试人员(test环境)或者产品人员(int环境)提出的BUG,先在dev分支上修改验证通过之后,合并到test分支,测试人员(test环境)或者产品人员(int环境)在进行复测;

3.4 修改用户验收环境 Bug

release 测试出现了Bug,首先要回归下 dev 分支是否同样存在这个问题。

  • 如果存在,修复流程 与(3.3)章节修复修复测试和集成环境 Bug流程一致。
  • 如果不存在,大部分是历史数据问题,环境配置等造成的。

3.5 修改正式环境 Bug

master 测试出现了Bug,首先要回归下 releasetest 分支是否同样存在这个问题。

  • 如果存在,修复流程 与 修复测试环境 Bug流程一致。
  • 如果不存在,大部分是历史数据问题,环境配置等造成的。

3.6 紧急修复正式环境 Bug

需求在测试环节未测试出 Bug,上线运行一段时候后出现了 Bug,需要紧急修复的。

  • 如果 release 分支存在未测试完毕的需求,就基于 master 创建 hotfix-240131 分支,修复完毕后,临时更换一下uat环境对应的包(hotfix-240131 分支提供的包)进行验证,验证成功之后,投入pro生产成功,合并代码到master,将master 代码合并到releasetestdev 分支 ,同时基于hotfix-240131 分支创建一个tag,描述具体的功能点,然后删掉 hotfix-240131 分支。
  • 如果 release 分支不存在未测试完毕的需求,但 test 分支存在未测试完毕的需求,就基于 release 创建 hotfix-240131 分支,修复完毕后发布到 release 验证,后面流程与上线流程一致,验证完毕后,将 master 代码合并到testdev 分支 ,同时基于hotfix-240131 分支创建一个tag,描述具体的功能点,然后删掉 hotfix-240131 分支。

3.7 并行提测

在一个项目中并行开发了两个需求,并行提测,但是上线日期不同,分支A先上线,分支B后上线;

  • 基于后上线分支B的版本分支新建一个可供测试验证的测试分支C,并将提前上线的 分支A 合并到测试分支C上;
  • 如果分支A出现BUG,研发人员现在分支A上调整之后再合并到测试分支C;如果分支B出现BUG,研发人员现在分支B上调整之后再合并到测试分支C

以上内容是根据自己所接触项目实际场景整理的,欢迎提供建议,不断完善git分支管理规范;

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/一键难忘520/article/detail/1019568
推荐阅读
相关标签
  

闽ICP备14008679号