基线模型与需求分支
本页给出第二种协作组织方式：主分支作为稳定基线，每个需求单独开一条分支，分支修改经评审后同步回基线。它适合发版频度较低、建模人员较多、需求之间相对独立的项目。
图示主分支与多个需求分支的并存关系，各分支互不干扰，变更最终汇集回主分支。
适用项目特征
| 特征 | 说明 |
|---|---|
| 发版频度 | 较低，多个需求合并后统一发布 |
| 建模人员规模 | 较多，需要在独立分支上并行工作 |
| 需求粒度 | 每个需求可以独立成支，相互影响较小 |
| 基线要求 | 主分支长期保持稳定，随时可作为发布基准 |
发版频度高、每次发布都要独立留痕的项目，更适合主线模型与发布分支。
结构与命名
text
master
├── sub branch feature1
│ └── feature：设计任务号 001 → version
├── sub branch feature2
│ └── feature：设计任务号 002 → version
named version（发版号）操作链路
- 模型管理员确认主分支状态，主分支上只保留已评审的内容。
- 按需求从主分支创建分支，分支名体现需求或设计任务编号，操作见模型分支管理。
- 在需求分支上完成设计与自检，签入版本。
- 发起评审，评审对象是该分支上的指定版本。
- 评审通过后，把分支变更同步回主分支；同步过程若冲突，先合并再提交。
- 对主分支申请发布某个迁入版本，形成命名版本。
- 选择上一个发版与当前发版两个版本生成 Alter 脚本，交由 DevOps 发布执行。
图示同步回主分支后的版本序列，命名版本标记了本次发布对应的基线状态。
冲突与自动合并的前提
在需求分支上的修改不会与他人冲突，因为该分支只由本需求的相关人员修改。冲突集中出现在把分支变更同步回主分支的环节。
- 自动合并需要满足前提条件，例如两侧改动落在不同对象上、所选版本的实体状态与目标分支一致；不满足时仍需手工处理。
- 手工处理方式与一个模型多人协作模式一致：用模型比较逐项决定保留哪一侧。
- 比较时开启“依据合并来源进行比较”，可以让改了名的同一对象仍落在同一位置比对。
| 现象 | 排查顺序 |
|---|---|
| 同步时提示大量冲突 | 先看主分支是否已被其他需求分支改动过同一对象，再决定合并顺序 |
| 无法选择某个版本参与合并 | 检查所选分支起始版本的实体状态是否与当前分支一致、版本是否连续 |
| 合并后主分支内容不符合预期 | 复核合并方向，确认是以哪一侧为准覆盖了另一侧 |
生成变更脚本并交付
- 确认本次发布对应主分支上的某个命名版本。
- 进入变更脚本生成入口，选择两个版本之间的变更脚本。
- 选择上一个发版与当前发版两个版本，产生 Alter 脚本。
- 预览并核对脚本范围，导出后交由 DevOps 按发布流程执行。
注意事项
- 主分支上应只保留已评审内容，避免在基线分支上直接改动而绕过评审。
- 需求分支的合并顺序应事先约定：先合入的分支会改变主分支状态，影响后续分支的冲突范围。
- 分支长期不合入会累积差异，同步成本随之上升，应约定合入节奏。
- 需求分支完成并合入后可封存，封存后不能再保存与签入，见模型分支管理。