Onshape合并的变化从哪里算起：当前两份模型之外还有base

两个工作区看起来不同，并不意味着Onshape的合并对话框就会把它们之间的所有表面差异当作本次待合并变化。理解这份资料，需要同时认识Source、Target和base三个对象，而不是只保留两张模型截图。

Onshape官方Merging说明将Source定义为被合入的文档版本或工作区，Target则是当前活动工作区。文档解释，合并取从base到Source的增量，再应用到Target；base是两者分支所依据的共同祖先。这里的起点决定了“变化”相对什么状态而言。

对于Merge changes，原文进一步说明，base可以是分支分开的那个变更点，例如创建分支的版本。如果同一Source分支此前已合入这个Target，并且那次合并没有被撤回，base也可以是上一次这样的合并点。因此，不能不看合并历史，就始终把最初分支版本写成本次计算起点。

这会影响对“没有变化”的理解。页面在Branches without changes部分明确提醒，没有变化指的是base到Source的增量，不是任意两个当前分支之间的外观比较。本文不根据实际模型判定哪一方更新，也不把界面没有待合并项解读为两份设计已获同样的工程批准。

三个策略的名称同样需要保留。Keep保留Target的变化，Merge changes组合双方变化，Replace则用Source替代Target中的变化。文档还允许对单独的标签页指定策略，并说明不能在一个标签页内逐项挑选变化。这里解释的是选项范围，不是推荐某种生产合并方案。

对产品生命周期资料交接，本文的分析是：合并说明若能写清来源、目标、base依据和各标签页采用的策略，后续读者才较容易理解一次记录到底表达什么。只写“已合并最新设计”，会掩盖来源是版本还是工作区，也会掩盖本次是否延续了先前同方向的合并。

该帮助页标注最后更新于2026年9月24日，本文只采用正文对对象、增量和策略的解释，没有从配图读取模型变化或复现合并操作。软件合并记录也不等于结构验证、工艺认可或工程放行。在讨论最终设计是否可用以前，先准确说明变化的计算起点，是一项独立的信息核对工作。