测试开发之源码篇-代码分支策略
原创- 2023-05-31 15:04:15
- 1728
本篇目录
一、主干开发
- 开发持续向主干提交代码,并基于主干进行测试验证;
- 在主干上修复缺陷,再同步修正的代码到需要的发布分支上;
- 每次均基于主干,创建指定版本的发布分支;
- 可享受持续集成、验证、交付带来的好处,消除不必要的分支切换和代码合并工作;
- 如果有众多成员同时工作在一个主干上,相互间容易干扰、引发代码冲突等问题;
- 可借助特性切换机制(如部署时的配置、代码中的判断),来规避不同版本间的差异(如隐藏不成熟的特性,赋予社区版和专业版不同功能),容易引发新的问题和复杂性。
二、Git Flow
- 开发人员在特性分支上实现新的特性,并提交代码;
- 频繁将特性分支上的代码合并到开发分支,并做集成测试;
- 集成开发分支上的代码到发布分支,完成集成和系统测试;
- 推送发布分支上的代码到主干进行发布;
- 在修复分支上修复线上缺陷,验证通过后发布补丁,并同步到主干和开发分支;
- 始终将主干视作整个项目的基线,并在其上对标各个版本的快照;
- 如果长时间在特性分支上工作,可能会导致朝开发分支上合并时产生冲突;
- 可选择性地省略开发或发布分支,在主干上完成持续集成和发布;
- 可选择性地省略修复分支,在特性分支上完成线上问题的修复。
三、Github Flow
- 从主分支创建一个特性分支,用于开发;
- 在特性分支上完成开发后,提交一个Pull Request(PR)申请向主分支推送代码;
- 组织相关人员对PR代码进行审查,合并主分支上的代码进行测试和验证;
- PR批准后,合并代码到主分支,删除特性分支;
- 编译、打包主分支上的最新代码,部署到生产环境;
- 该模型频繁合并代码,进行自动化集成、验证和部署,符合CI和DevOps工程学理念;
- 可持续向主干集成有价值增量,尽早在可运行的完整系统上进行测试验证,符合敏捷开发的精神;
- 该模型更适合于运营在相同环境下、沿着单线演进的项目,如在线服务;
- 对于一些在不同客户处、有很多不同版本的产品,以及规模较大的工程或团队,会有一定难度。
四、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)、不同版本系列(如社区版、专业版)上,进行功能的划分和组合。