禅道博客

分享专业技术知识,文章内容干货满满

测试开发之源码篇-代码分支策略

2023-05-31 15:04:15
陈琦
原创 1088
摘要:本文介绍了常见的代码分支策略,包括主干开发、Git Flow、Github Flow和Gitlab Flow。每种策略都有其适用场景和优势,可以根据项目需求选择合适的代码分支策略。

一、主干开发

主干开发

  • 开发持续向主干提交代码,并基于主干进行测试验证;
  • 主干上修复缺陷,再同步修正的代码到需要的发布分支上;
  • 每次均基于主干,创建指定版本的发布分支
  • 可享受持续集成、验证、交付带来的好处,消除不必要的分支切换和代码合并工作;
  • 如果有众多成员同时工作在一个主干上,相互间容易干扰、引发代码冲突等问题;
  • 可借助特性切换机制(如部署时的配置、代码中的判断),来规避不同版本间的差异(如隐藏不成熟的特性,赋予社区版和专业版不同功能),容易引发新的问题和复杂性。

二、Git Flow

Git Flow
  • 开发人员在特性分支上实现新的特性,并提交代码;
  • 频繁将特性分支上的代码合并到开发分支,并做集成测试;
  • 集成开发分支上的代码到发布分支,完成集成和系统测试;
  • 推送发布分支上的代码到主干进行发布;
  • 修复分支上修复线上缺陷,验证通过后发布补丁,并同步到主干和开发分支;
  • 始终将主干视作整个项目的基线,并在其上对标各个版本的快照;
  • 如果长时间在特性分支上工作,可能会导致朝开发分支上合并时产生冲突;
  • 可选择性地省略开发或发布分支,在主干上完成持续集成和发布;
  • 可选择性地省略修复分支,在特性分支上完成线上问题的修复。

三、Github Flow

Github Flow
  • 主分支创建一个特性分支,用于开发;
  • 特性分支上完成开发后,提交一个Pull Request(PR)申请向主分支推送代码;
  • 组织相关人员对PR代码进行审查,合并主分支上的代码进行测试和验证;
  • PR批准后,合并代码到主分支,删除特性分支
  • 编译、打包主分支上的最新代码,部署到生产环境;
  • 该模型频繁合并代码,进行自动化集成、验证和部署,符合CI和DevOps工程学理念;
  • 可持续向主干集成有价值增量,尽早在可运行的完整系统上进行测试验证,符合敏捷开发的精神;
  • 该模型更适合于运营在相同环境下、沿着单线演进的项目,如在线服务;
  • 对于一些在不同客户处、有很多不同版本的产品,以及规模较大的工程或团队,会有一定难度。

四、Gitlab Flow

Gitlab Flow
  • 对应Github Flow中的Pull Request(PR),存在一个名为Merge Request(MR)的过程;
  • 在发布侧(图中Master分支以上部分),增加了 预产品分支产品分支
  • 主分支产品分支代码的Promotion,需逐层提交MR进行评审和验证;
  • 通常在Master分支上修复缺陷,再逐层Promote到上层产品分支;
  • 需维护集成环境(对应Master分支)预上线环境(对应预产品分支生产环境(对应产品分支多个环境;
  • 相比Github Flow,更适合于同时需要维护多个版本的、对外发布的产品;
  • 推荐以单个特性的颗粒度,完成从Feature分支Master分支的Merge Request,以方便日后在产品的不同版本编号(如V1.0、V2.0)、不同版本系列(如社区版、专业版)上,进行功能的划分和组合。
暂时没有记录
评论通过审核后显示。