分支合并后出现工件重复，表面看是合并把同一条需求或用例变成了两条，根因通常是分支期间发生了并行新增、复用方式选错、或在仓库层合并时把两份对象都保留下来。Polarion的分支与复用能力很灵活，但如果没有先把“哪些内容允许在分支新增”“哪些内容必须引用而不是复制”“合并只走哪一条通道”定清楚，就很容易在回主线时把重复带回去，后续报表、追溯与测试执行都会被污染。

　　一、Polarion分支合并后工件重复是什么问题

　　分支合并带来的重复，通常不是系统随机生成，而是对象语义在不同载体里被复制了一次，合并后两份都可见。先把重复的来源类型区分清楚，后续才能选对去重动作。

　　1、分支与主线同时新增了同一语义的工件

　　同一条需求在主线有人新建，分支里也有人新建，两个工件ID天然不同，合并时属于新增加新增，系统不会自动判定它们“应该是同一条”，合并后就表现为重复。

　　2、把应引用的工件做成了复用复制

　　在LiveDocs里如果使用了复用复制的方式，把原工件复制成新工件再放入文档，那么它本质就是两条工件，合并只会把两条都带回来；相反，如果用引用方式把同一工件展示在多份文档里，就不会产生新工件。Polarion官方对复用与引用有明确区分，复用会产生副本，引用只建立关联。

　　3、分支与主线的引用方向用反了

　　在分支文档里新建工件后，如果把它反向引用到主线文档里，后续再做合并与整理时，很容易出现主线既保留了原工件，又被插入了分支新工件的引用，最终看起来像重复。Polarion的实践建议是引用方向从分支指向主线，而不是反过来。

　　4、跨空间跨范围复制导致ID变化

　　当把工件复制到另一个范围或另一条分支时，哪怕内容完全相同，ID也会变化，合并无法把它当作同一个对象折叠；尤其是跨范围分支场景里，官方也提示不能通过移动来保持同一ID，只能复制并保持链接关系，这本身就意味着会出现新对象。

　　5、绕开Polarion界面合并，直接用SVN做仓库级合并

　　Polarion的工件与文档底层落在SVN即Subversion仓库中，若用svn merge在仓库层强行合并，冲突解决时很容易把两份对象内容同时保留，最后在Polarion里看到的就是两条工件并存，而不是一条工件的变更被合入。

　　二、Polarion分支合并规则与去重应怎样设置

　　要把重复压下去，核心不是事后删工件，而是把分支期间的新增权限、复用方式、合并通道三件事固化成规则，并在界面里按固定路径执行合并与去重。

　　1、先把分支的职责边界写进团队约定并映射到执行动作

　　约定主线只接收合并结果，分支用于变体改动与新增草稿，避免主线与分支同时新增同一语义工件；落实到操作上，分支人员在创建新工件前先在【Work Items】里用标题和关键字段检索主线是否已存在，确认不存在再建，并在描述中写明分支来源与意图，便于合并时人工判定同源关系。

　　2、在LiveDocs里优先使用引用而不是复制来复用内容

　　需要同一批工件出现在多份文档时，先在目标文档点击【Insert】选择【Referenced Work Items】，用引用方式把工件插入为引用项，而不是复制生成新工件；官方示例指出，引用方式能把大量工件集中展示在主文档里，但工件并不实际包含在该文档中，从机制上避免了复制型重复。

　　3、需要建立父子关系时用复制ID加链接而不是复制工件

　　在文档中要建立父子或关联关系时，选中父工件，使用工件菜单的【Copy ID】，再在子工件侧边栏属性里粘贴形成链接，不要用复制工件的方式去“再生成一条父工件”；Polarion的LiveDocs实践文章给出了复制ID再粘贴建立链接的典型流程。

　　4、分支合并尽量走文档级合并能力并开启自动合并

　　对分支文档与主线文档的合并，优先在文档界面使用【Compare】与【Merge】类入口进行三方合并，避免只在仓库层合并；在支持的版本中，自动合并可以把简单改动自动处理，并支持把分支对工件的修改、删除与新增合入主线，也支持反向从主线拉回分支，适合用来建立稳定的推送与拉取节奏。

　　5、建立去重操作的标准动作，先替换引用再处理多余对象

　　在确认两条工件语义重复后，先选定保留工件作为权威项，再到包含重复项的文档里选中重复工件，使用文档侧的删除入口如【Remove】将其从文档移除，然后通过【Insert】里的【Referenced Work Items】插入权威工件的引用，确保文档结构不丢；最后再在【Work Items】列表中对多余工件做归档或状态标记，并用工件链接类型标记为重复来源，便于审计追溯。

　　6、需要更快发现重复时引入重复提示与对比工具

　　如果团队规模较大，建议在工件表单侧引入重复提示面板，用于在创建或编辑时自动检索相似工件并提示可能重复；Polarion扩展库中提供了在工件表单上展示可能重复项的扩展，可作为去重前置提醒。

　　对合并前后的差异核对，可使用对比类扩展进行文档与工件差异比对，并支持按查询过滤后再对比，适合在合并窗口前做一次去重预检查。

　　三、Polarion工件去重核验与长期管控

　　规则设好后，还需要把去重结果核验与长期管控变成固定动作，否则下一次合并仍会把重复带回来。

　　1、把合并前核验变成必走清单

　　在准备合并前，先在【Work Items】用统一查询条件列出本次分支新增工件，再用相同条件在主线检索相似项，人工确认哪些应转为引用、哪些确实是新需求，避免合并后才做大规模清理。

　　2、把重复的处理口径统一为可审计的闭环

　　对确认重复的工件，不建议直接硬删，优先用状态标记、归档与链接说明把处置过程留痕，保证后续追溯时能解释为什么合并后减少了条目，避免在审计或复盘中出现口径断点。

　　3、对分支新增设置最低信息要求

　　要求分支新增工件必须填写来源分支、适用版本、变体标识等关键字段，并在标题命名上引入可区分的前缀或编号规则，这样即使出现语义接近的内容，也能快速判断是否同源变体还是误重复。

　　4、定期对文档层复用方式做抽查

　　每个迭代结束后抽查关键LiveDocs，重点检查是否使用了引用插入而不是复用复制，尤其是测试用例与安全需求这类高复用对象，优先把复用复制改造成引用，降低下一个合并周期的重复风险。

　　总结

　　分支合并后的工件重复，最常见的本质是并行新增与复制型复用叠加，再加上合并通道选错导致两份对象被同时保留。治理思路应从源头入手，把复用优先改为引用，把合并优先放在Polarion文档级合并能力上，并用标准去重动作先替换引用再处置多余对象，同时配合重复提示与差异对比工具，把重复拦在合并前而不是合并后。