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

一、主干开发

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

二、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）、不同版本系列（如社区版、专业版）上，进行功能的划分和组合。