主线模型与发布分支

本页给出第三种协作组织方式：主线模型保持演进，每次发布从主线开出一条分支进行设计、评审与发布，发布完成后把变更回并主线。它适合发版频度高、每次发布都要独立留痕的项目。

图示主线上依次开出的发布分支，每个分支对应一次发布，分支上的版本序列相互独立。

适用项目特征

特征	说明
发版频度	高，每个发布周期都要形成独立版本
建模人员规模	较多，多个设计与开发任务并行推进
留痕要求	每次发布的模型状态需要可以单独定位与复现
主线状态	主线持续演进，承载已完成并回并的变更

结构与命名

master
├── sub branch 1.0（发版号）
│   ├── feature：设计任务号 001 → version
│   ├── feature：设计任务号 002 → version
│   └── merge to master
└── sub branch 2.0（发版号）
    ├── feature：设计任务号 001 → version
    ├── feature：设计任务号 002 → version
    └── merge to master

分支名建议直接采用发版号，便于脚本生成时按发版号选择版本。

操作链路

1. 从主线创建一条发布分支，分支名使用本次发布号，操作见模型分支管理。
2. 在发布分支上按设计任务继续推进，任务级改动作为该分支下的版本提交。
3. 分支内容完成后发起评审。
4. 评审通过，在发布分支上形成本次发布的命名版本并发布。
5. 发布后把该分支的变更回并主线；回并过程若冲突，先比较合并再提交。
6. 开始下一次发布时，从主线重新开出一条新分支，重复上述流程。
7. 选择上一次发布与本次发布两个版本生成 Alter 脚本，交由 DevOps 发布执行。

图示回并主线后的版本序列，各发布分支的命名版本构成发布台账，主线则汇总全部已回并内容。

与基线模型加需求分支模式的差异

对比项	主线模型与发布分支	基线模型与需求分支
分支的划分依据	按发布周期开分支，分支名即发版号	按需求开分支，分支名即需求或任务号
适合的发版频度	高，每次发布独立成支	低，多个需求合并后发布
主线角色	持续演进，接收各发布分支回并	保持稳定，作为发布基准
回并时机	分支发布完成后回并主线	分支评审通过后同步回主分支
命名版本位置	落在发布分支上，作为发布节点	落在主分支上，作为发布基准节点
典型冲突场景	回并主线时与主线最新内容冲突	同步回基线时与其他需求分支冲突

两种模式都以模型比较处理冲突、以版本为单位生成变更脚本，差异主要在分支的划分依据与回并时机。仅需要多人并行、不区分发布分支的团队，可参考一个模型多人协作模式。

生成变更脚本并交付

1. 确认本次发布对应的命名版本已经生成。
2. 在变更脚本生成入口选择两个版本之间的变更脚本。
3. 选择上一次发布的版本与本次发布的版本。
4. 预览脚本并核对变更范围，导出后交由 DevOps 执行。

注意事项

• 发布分支形成命名版本后建议封存，防止发布后继续在分支上改动，导致版本与交付内容不一致。
• 回并主线越晚，主线累积的改动越多，冲突范围越大，应约定发布后的回并时限。
• 每条发布分支只用于一次发布，不要在旧分支上继续下一次发布的设计。
• 变更脚本按版本对比生成，版本缺失会直接影响交付，参见历史版本。