BG1热修复开发分支
创建
合并
反向合并到R1、T1、特性分支
v1.1.0
F-11 F-12
1、2个组热修复： 1）针对同一版本：各组分别在BG上开发，合并到R2进行集成测试 2）针对不同版本：各组直接在BG上修改、测试、发布，不需要R2（如果只有1个热修复环境，则只能协商哪个先发，哪个后发）2、1个组热修复：直接在BG上修改、测试、发布，不需要R2根据是否有多个BG来确认是否需要合并到R2（先创R2，再合并BG到R2），R2的创建来源跟BG一样即可热修复场景： 场景1：红色线条：仅1个组有热修复 场景2：2个组对同一个版本热修复，一起发布（灰色线条所示） 场景3：2个组对同一个版本热修复，分开发布，先发布的要反向合并到后发布的BG分支（湖蓝色线条） 场景4：所有组对同一个版本热修复（场景2、3可已覆盖） 场景5：2个组对不同版本热修复，只能分开发布（同场景三，且不需要反向合并） 场景6：3个组有2个组对同一版本热修复、1个组对另一版本热修复（在上面的场景2、3、5中已覆盖）热修复先考虑多个团队共用一个开发分支处理
Tn分支
测试通过冻结特性分支
反向合并
Master
特性分支
多团队协作分支管理策略-V1.0
T1分支
R1预发布分支
Tag
v1.0.0.1
正常迭代
v1.0.0.2
热修复场景说明：场景一：仅一个组要热修复，则从Tag拉R2、BG分支，在BG分支开发完成后，将其合并到R2进行测试，测试通过则可直接发布（仅看BG2泳道即可）场景二：多个组都要热修复，且可以一起发布的情况：每个组拉取自己的BG分支，开发完成后，统一合并到R2分支，一起测试通过后一起发布（看BG1、BG2泳道）场景三：多个组都要热修复，但无法一起发布的情况：每个组拉取自己的BG分支，先开发测试完成的先上线，后开发完的后面再上线（看BG1、BG2、BG3泳道，BG1、BG2先上线，BG3后上线）（这里BG3也没办法提前测试，需要等待BG1和BG2上线后，才能将BG3合并到R2上开始测试）
预发布验证通过，发生产，代码合并到主干并打tag
v1.0.0
调整点：1、开始迭代，创建T1、R1、R2需要取消，放到代码合并到T1、R1、R2的时候先创建，再合并F；BG分支在特性开始开发时创建问题1、迭代版本与发布版本拆开，发布版本中的镜像tag如何自动更新：测试构建要更新环境的tag、预发布构建要更新发布版本的tag2、有需要对历史版本热修复的场景？ 如果存在，那么当1组是对历史版本热修复，2组是对最新版本热修复，如果开发完后要一起发布会如何操作？ =>2组只能分开发布，如果有多个热修复环境，那可以并行发布，用各自的BG分支合并到不同的R分支进行测试后发布（这个暂时不实现，实现的话需要考虑运行时可指定要合并到哪个R分支）
R2热修复测试
测试通过冻结BG分支，发生产，代码合到主干并打tag
BG3热修复开发分支
F-n1 F-n2
BG2热修复开发分支
热修复
