多分支并行修复时，一个缺陷往往对应主分支的原始修复提交和若干发布分支上的 cherry-pick 提交。cherry-pick 会在目标分支生成新的提交哈希，原来贴在缺陷单上的那条提交链接就覆盖不到新分支，追溯关系容易在这里断开。本文从缺陷视角出发，说明如何把“缺陷—原始修复提交—各分支落地提交”建成一对多的显式关联，并给出登记、回填与核对的具体做法。
要点总览（TL;DR）
- cherry-pick 会在目标分支生成新提交哈希，缺陷单只贴一条原始提交链接时，追溯链在“原始提交→派生提交”这一跳断开。
- 把缺陷单作为主记录：原始修复提交作为主关联，每次 cherry-pick 产生的提交以派生提交身份逐条追加，记录哈希、目标分支、来源提交和落地状态。
- 合并请求描述回填缺陷号与来源提交，缺陷单指向合并请求，形成双向可查；多仓库场景在记录中带上仓库标识。
- 核对按“仓库+分支”组合逐项进行，结果分为已覆盖、未覆盖、不适用，不适用需写明理由。
- 用抽样核对、反向核对和遗漏率、回填及时性两个指标验证追溯是否真正可核对，并按周期重复观察。
当前做法与目标：多分支修复下追溯为何容易断
多分支并行修复的典型流程是：开发在主分支完成修复并提交，验证通过后，再把同一个修复 cherry-pick 到一条或多条发布分支。分支越多、发布窗口越紧，这个动作发生得越频繁。此时一个缺陷在代码侧留下的痕迹不再是一条提交，而是“一条原始提交 + N 条派生提交”。
当前常见做法通常只有两步：提交信息里写缺陷号，缺陷单里贴一个提交链接。这套做法在单分支修复时基本够用，因为缺陷单上的链接就是唯一需要找的那条提交。到了多分支场景，它只记录了链路的第一环，后续 cherry-pick 产生的提交没有任何登记位置。
本文要达成的目标可以拆成三条可核对的要求：
- 每条提交可定位：同一缺陷下的原始提交和每一条派生提交，都能通过哈希找到具体代码改动。
- 每条提交可核对：能看出这条派生提交来自哪条原始提交、落在哪个分支、当前处于什么状态。
- 落地分支可判断：给定一个缺陷和一份受影响分支清单，能逐条判断每个分支是否已有对应提交。
这三条要求共同指向一个结论：追溯关系需要显式记录，不能靠分支名、提交信息或发布单去反推。
瓶颈与误区：追溯断在哪几个环节
追溯断裂有具体的发生位置，分清这些位置，才能判断改进动作应该加在哪一步。
cherry-pick 产生新哈希，原链接失效
cherry-pick 的本质是把改动重新应用到目标分支并生成一条新提交，新提交的哈希与原始提交不同。缺陷单上贴的原始提交链接指向的是主分支的那次提交，在发布分支上既看不到它，也无法从它跳转到派生提交。追溯链在“原始提交 → 派生提交”这一跳上断开，这是最直接的原因。
提交信息里的缺陷号不稳定
把缺陷号写进提交信息，依赖的是提交信息在整个流转过程中保持不变。实际协作中，合并可能触发压缩提交，变基可能改写提交信息，不同人填写格式也不统一，缺陷号可能丢失，也可能在多个提交中重复出现。用缺陷号做检索键，得到的结果既不完整也不唯一。
缺陷单只记一条提交，分支覆盖不全
一个缺陷对应多次提交时，缺陷单通常只保留一条记录。这条记录可能是最早的主分支提交，也可能是最后一次 cherry-pick 的提交，无论哪种，都无法回答“哪些分支已经修了、哪些还没修”。发布前判断影响范围时，这个缺口会直接变成遗漏风险。
把分支名或发布单当作追溯依据
常见的误区是用分支命名规范（如带缺陷号的分支名）或发布单里的修复清单来代替提交级关联。分支名只能说明“有人在这个分支上动过”，无法证明改动就是该缺陷的修复；发布单记录的是发布批次，粒度比缺陷粗，且往往在发布前才整理。两者都可以作为辅助线索，承担不了追溯主记录的角色。
优先改进动作：建立缺陷与提交的一对多关联
改进的核心是把缺陷单变成提交关联的主记录：原始修复提交作为主关联，每次 cherry-pick 产生的提交作为派生提交追加到同一缺陷下。下面按字段设计、登记时机、双向回填和核对四步展开。
第一步：在缺陷单上设计两类提交字段
原始修复提交与派生提交在含义上不同，建议分开记录，避免混在一张清单里难以区分主次。
| 字段 | 含义 | 填写时机 |
|---|---|---|
| 原始修复提交 | 主分支上完成该缺陷修复的提交哈希 | 修复提交合入主分支后 |
| 派生提交清单 | 每条 cherry-pick 产生的提交，逐条记录 | 每次 cherry-pick 完成后 |
| 派生提交—提交哈希 | 目标分支上新生成的提交哈希 | 同上 |
| 派生提交—目标分支 | 该提交落地的分支名称 | 同上 |
| 派生提交—来源提交 | 对应的原始修复提交哈希 | 同上 |
| 派生提交—落地状态 | 已合入、待验证、已回滚等状态 | 状态变化时更新 |
| 仓库标识 | 提交所在代码仓库（多仓库场景必填） | 与提交哈希同时填写 |
派生提交清单是一对多关系中的“多”这一侧，每条记录独立成行，而不是把多个哈希拼在一段文本里。这样后续核对时可以逐行比对分支，也便于标记某条提交被回滚。
第二步：cherry-pick 完成后立即登记
登记时机直接影响追溯的及时性。建议把“cherry-pick 完成”作为登记触发点，而不是等到发布前统一补录。具体动作是：在目标分支完成 cherry-pick 并推送后，回到缺陷单追加一条派生提交记录，填写新哈希、目标分支、来源提交和当前落地状态。如果 cherry-pick 过程中出现冲突并做了额外调整，应在记录中注明，因为此时的派生提交与原始提交在内容上已不完全一致。
第三步：合并请求描述回填缺陷号与来源提交
缺陷单是缺陷侧的主记录，合并请求是代码侧的主记录，两边都需要能查到对方。在合并请求描述中回填缺陷号和来源提交哈希，使代码评审者在评审时就能看到这次改动对应哪个缺陷、来自哪条提交；缺陷单上的派生提交记录则指向这个合并请求。两边互相指向，形成双向可查，任何一侧作为入口都能走通整条链路。
第四步：按分支清单逐项核对
核对的动作是：先确定该缺陷受影响的分支清单，再对照缺陷单上的派生提交记录，逐个分支确认是否已有对应提交。核对结果只有三种——已覆盖、未覆盖、不适用（该分支不含此缺陷的修复范围）。第三种情况需要写明理由，避免把“没修”误判成“不需要修”。多仓库场景下，分支清单要带上仓库标识，按“仓库 + 分支”的组合逐项核对。
这套登记与核对动作需要有承载位置。ONES Project 适配缺陷管理等场景，支持缺陷跟踪管理并统计缺陷状态分布，缺陷可以在项目或迭代中记录和跟踪修复情况；派生提交的哈希、目标分支、来源提交和落地状态，可以作为缺陷工作项上的记录项随缺陷一起维护，核对时直接从缺陷侧读取提交清单。ONES Project 与其它应用及模块数据互通，便于把缺陷记录与研发协作中的其他环节放在同一处查看。代码提交与缺陷工作项之间的直接关联方式，以团队实际使用的代码托管集成配置为准。
适用前提与代价：这套做法需要什么条件
这套做法成立的前提是提交哈希能够稳定获取、受影响分支能够枚举。前者要求团队使用统一的代码托管平台并能查到提交记录，后者要求发布分支有明确清单，而不是临时从分支列表里挑。两个条件任一不满足，一对多关联就缺少比对基准。
代价主要在流程成本上。每次 cherry-pick 后主动登记一条记录，意味着开发在完成代码动作之外多一步操作。分支多、发布频繁时，这一步容易被跳过，因此需要把登记纳入 cherry-pick 的完成定义，而不是作为可选项。
多仓库场景还有额外成本：同一缺陷的修复可能涉及多个仓库，记录中必须带仓库标识，否则同名分支或相似哈希前缀会造成混淆，核对时反而增加排查量。
如果流程约束显得过重，可以按风险做简化取舍：只对发布分支强制登记派生提交，特性分支和临时分支依靠合并请求描述回填；核对频率从每次 cherry-pick 降为发布前集中核对一次。简化的代价是追溯的实时性下降，发布前集中核对的工作量会上升，团队需要根据发布节奏选择。
效果验证：怎么判断追溯关系真的可核对
验证的目标是确认追溯关系能被独立核对，而不是确认“大家觉得记录得挺全”。建议用抽样核对和反向核对两种方式，配合两个观察指标。
抽样核对：从缺陷查分支覆盖
随机抽取一批近期发生过 cherry-pick 的缺陷，对每个缺陷取出受影响分支清单，逐项检查缺陷单上的派生提交记录是否覆盖所有目标分支。抽样时应有意识覆盖不同发布分支和不同修复人，避免样本集中在同一条链路。发现未覆盖的分支，记录是漏登记还是确实未修复。
反向核对：从提交回溯缺陷
从发布分支上随机取若干提交，检查能否通过合并请求描述或缺陷单唯一回溯到某个缺陷。反向核对重点看“唯一”：如果一条提交对应多个缺陷，或一个缺陷号对应多条无关提交，说明关联记录存在重复或错挂，需要清理。
观察指标
- 遗漏率：抽样缺陷中，存在未覆盖目标分支的比例。这个指标直接反映追溯完整性。
- 回填及时性：从 cherry-pick 完成到派生提交登记之间的时间间隔。间隔越长，发布前集中补录的概率越高，记录质量越难保证。
验证结果应反馈到流程调整：遗漏集中在某类分支，就把该类分支纳入强制登记范围；及时性差，就检查登记动作是否被放在了合适的节点，例如是否可以在合并请求创建时一并完成。验证按固定周期重复进行，观察指标是否随流程调整而变化，才能判断改进是否真正生效，而不是把某次抽样结果当作长期结论。
常见问题
cherry-pick 时如果解决了冲突、改动和原始提交不完全一致，派生提交记录要怎么写？
在派生提交记录中注明“cherry-pick 时有冲突调整”，并简要说明调整内容。此时派生提交与原始提交在代码内容上已不完全一致，追溯关系仍然成立，但核对时不能默认两者等价。如果冲突调整改变了修复逻辑，建议评估是否需要同步回主分支，避免各分支修复行为出现差异。
发布分支很多、cherry-pick 频繁时，每次都登记派生提交成本太高，可以怎么简化？
按风险分层处理：对发布分支强制登记派生提交，特性分支和临时分支依靠合并请求描述回填缺陷号与来源提交；核对频率从每次 cherry-pick 降为发布前集中核对一次。简化的代价是追溯实时性下降、发布前核对工作量上升，团队需要结合发布节奏决定分层范围，并保证被简化的分支仍能从合并请求侧回溯。
多仓库场景下，同一缺陷的修复分散在不同仓库，核对时要注意什么？
分支清单要带上仓库标识，按“仓库+分支”的组合逐项核对，不能只按分支名比对。派生提交记录中必须填写仓库标识，否则同名分支或相似哈希前缀会造成混淆。核对时先确认该缺陷涉及哪些仓库，再逐个仓库检查目标分支是否已有对应提交，避免因只查了主仓库而漏掉其他仓库的落地情况。
缺陷单上的派生提交记录和合并请求描述，哪个应该作为追溯的主依据？
缺陷单是缺陷侧的主记录，合并请求是代码侧的主记录，两者互为入口，不设单一主依据。缺陷单上的派生提交清单用于回答“这个缺陷修到了哪些分支”，合并请求描述中的缺陷号与来源提交用于回答“这次改动对应哪个缺陷、来自哪条提交”。核对时两边比对，任何一侧缺失都说明回填不完整。
抽样核对发现遗漏后，怎么判断是流程问题还是执行问题？
先看遗漏的分布：如果集中在某类分支或某个发布窗口，通常是流程覆盖范围的问题，应把该类分支纳入强制登记；如果分散在不同修复人之间，更可能是登记动作没有被纳入 cherry-pick 的完成定义。再看回填及时性，登记间隔普遍偏长说明登记节点设置不合理，可以尝试把登记与合并请求创建合并为同一步骤。根据分布特征调整流程，再按周期重复抽样观察指标变化。
