一个模型多人协作模式

本页给出一种可照做的协作链路：多人共用一个模型的多个分支并行设计，评审后发布基线版本，冲突用比较合并解决，最后按两个发版版本生成 Alter 脚本交由 DevOps 执行。它适合设计任务密集、需要频繁小步提交的团队。

图示各分支的版本列表，每个分支对应一个设计任务，版本号用于区分同一分支上的多次提交。

结构与命名

master
├── feature：设计任务号 001 → version
└── feature：设计任务号 002 → version
named version（发版号）

层级	命名建议	作用
master	模型名称	主线，承载已评审并发布的基线
分支	feature 加设计任务号	一个设计任务一条设计线，互不干扰
版本	任务号加顺序号	分支上的提交节点
命名版本	发版号	评审通过后的基线节点，供脚本生成使用

操作链路

1. 模型管理员在模型库中建立模型，并为成员配置模型权限；权限口径见模型管理。
2. 每位建模人员按自己的设计任务，右键模型选择“创建分支”，得到以主分支为起点、只属于该任务的分支，参见模型分支管理。
3. 在各自分支上完成设计，用“签入版本”提交，版本号中体现设计任务号。
4. 全部任务分支提交完成后发起评审，评审对象是各分支上指定的版本。
5. 评审通过后，把各分支的变更合入主线，并发布一个命名版本作为基线。
6. 出现冲突时先解决再提交，处理方式见下一节。
7. 选定上一个发版与当前发版两个版本，生成 Alter 变更脚本，交由 DevOps 在生产执行。

评审通过后主分支上会推进出新的命名版本，它成为新的基线，后续脚本生成都以版本为单位。

冲突处理

冲突出现在提交或合入环节：同一对象被多方修改时，模型库无法自动判定保留哪一侧。

图示比较合并界面，红色行表示两侧内容存在差异，需要人工逐项决定保留哪一侧。

1. 提交或合入时若提示冲突，不要反复重复提交，先记录冲突涉及的对象。
2. 使用模型比较比较本地副本与模型库中的目标版本。
3. 在差异列表中逐项判断，用左右箭头把选定一侧的内容合并到另一侧。
4. 全部差异处理完毕后保存同步内容，再执行提交。

比较时开启“依据合并来源进行比较”，即使同一对象在两侧被改了名称，仍会放在相同位置显示差异，减少漏配对的情况。

生成变更脚本并交付

图示生成变更脚本时选择两个版本的界面，选择上一个发版与当前发版即可得到两者之间的 Alter 语句。

1. 确认当前发版已在模型库中形成命名版本。
2. 打开变更脚本生成入口，选择两个版本之间的变更脚本。
3. 分别选择上一个发版版本与当前发版版本，产生脚本。
4. 预览脚本内容，确认变更范围与预期一致。
5. 导出脚本文件或上传至代码库，交由 DevOps 按发布流程执行。

客户端侧的脚本操作见生成 DDL，Web 管理端的对应入口见脚本生成。

阶段与交付物

阶段	主要动作	产出
并行设计	各任务分支上编辑并签入版本	分支上的版本记录
评审	对指定版本发起评审	评审结论
发布基线	合入主线并发布命名版本	基线版本节点
冲突处理	用比较合并逐项确认差异	一致后的模型状态
脚本交付	按两个发版生成 Alter 脚本	可执行的变更脚本

注意事项

• 提交前确认当前分支是否正确，把变更提交到不属于自己任务的分支会增加后续合并成本。
• 共享模式下并发提交不会自动合并，冲突必须显式处理后再提交。
• 变更脚本由两个版本对比生成，因此每次发布都应保留一个可识别的命名版本。
• 评审与发布环节按组织制度执行，不同组织的审批节点可能与本页链路不同。
• 需要按需求分支组织时改用基线模型与需求分支；按发布开分支时改用主线模型与发布分支。