多分支并行修复同一个缺陷时，提交记录很容易散落在各条分支上：主分支合入了，发布分支还在修，cherry-pick 又生成了新哈希。本文给出一套以缺陷单为关联主键的维护方法，覆盖提交信息规范、缺陷单内的提交清单、合并与 cherry-pick 的追加规则，以及抽样核对方式。缺陷单需要承载这些记录，ONES 的工作项与缺陷跟踪能力可以作为管理承载方向。
要点总览（TL;DR）
- 把缺陷单当作关联的唯一主键：提交信息负责写入指针，缺陷单内的提交清单负责汇总，两个方向都能查。
- 提交信息统一写成“缺陷编号+类型（分支）+简述+来源提交”，cherry-pick 与回合并必须标注来源哈希。
- cherry-pick、回合并产生的新提交作为独立条目追加，不覆盖原条目，多仓库按仓库分组登记。
- 提交人、评审人、验证人分段维护清单，合并评审与发布分支创建后设检查点，防止漏记。
- 用抽样核对加关联缺失率、回合并未记录数、验证结果空缺数判断改进是否生效，样本小或分支策略变化时谨慎解读。
现状：多分支修复时提交关联为什么会散
多数团队已经在提交信息里写缺陷编号，这一步解决了“从提交能找到缺陷”的问题。多分支并行修复时，问题出在反方向：从缺陷单出发，很难确认这个缺陷到底被哪些提交改过、每条提交现在处于什么状态。常见做法是提交信息只写一个缺陷号，分支名和提交来源靠提交人自己记得；合并到主干后在群里说一声；cherry-pick 到发布分支时另起一条提交，信息里可能只保留缺陷号甚至省略。缺陷单本身只记录修复结论，不记录过程。
三类场景的散乱表现各有不同。并行分支场景下，同一缺陷在开发分支、预发分支、发布分支各有一条提交，缺陷单上看不到分支维度，无法判断哪条分支已修、哪条待修。多仓库场景下，一个缺陷可能涉及前端仓库和后端仓库，两条提交分属不同代码库，缺陷单里通常只留了一条链接或一句描述。cherry-pick 场景下，原提交被复制到目标分支后产生新哈希，原提交信息里的缺陷号可能被保留，但新提交与源提交的对应关系没有任何地方记录，回合并时同样如此。
改进目标可以写成两条可检验的要求：从任意一个缺陷单出发，能列出该缺陷在所有分支、所有仓库上的相关提交，并看到每条提交的类型与当前状态；从任意一条相关提交出发，能回溯到它所属的缺陷单，以及它是原始修复还是由哪条提交复制或回合并而来。两条要求同时成立，关联才算完整。
瓶颈与误区：关联断在哪一环
关联失效集中在几个具体环节。第一处是提交信息缺少分支与来源字段。只写缺陷号时，一条提交无法自证它属于哪条分支、是原始修复还是从别处复制来的。评审人看到两条带同一缺陷号的提交，无法判断它们是两次独立修复还是同一次修复的两个副本，回合并提交尤其容易被误认为重复劳动。
第二处是 cherry-pick 与回合并产生新哈希。Git 的 cherry-pick 会生成一条内容相近但哈希不同的新提交，原提交与目标分支上的新提交之间没有自动建立的关联。如果缺陷单里只登记了原始提交，发布分支上的实际修复就处于无记录状态；如果只登记了新提交，又丢失了它来自哪次修复。回合并（revert 后再 merge 或重新合入）同理，每次操作都产生新的提交对象，旧记录不追加就会失真。
第三处是缺陷单与代码库分属两个系统，状态靠人工同步。提交合入了，缺陷单状态还停在“修复中”；验证通过了，提交清单里没有验证结论。人工同步在分支少、节奏慢时勉强可用，一旦并行分支超过三四条，漏记几乎必然发生。
最常见的误区是把“主分支已合入”当成“所有分支已修复”。主分支合入只说明主干代码包含修复，发布分支、维护分支、客户定制分支是否已获得同一修复，需要逐条核对。另一个误区是认为提交信息写了缺陷号就等于关联完成，实际上缺陷号只建立了单向指针，缺陷单侧的提交清单仍需单独维护。
优先改进动作：用缺陷单承载提交清单
改进的核心是把缺陷单当作关联的唯一主键，提交信息负责写入指针，缺陷单负责汇总清单。两者配合，形成双向可查的链路。
统一提交信息格式
建议格式为：[缺陷编号] 类型(分支) 简述 - 来源:提交哈希。其中类型取“修复”“回合并”“cherry-pick”三类之一，分支写目标分支名，来源提交哈希仅在 cherry-pick 和回合并时填写。例如：[BUG-1024] cherry-pick(release/2.3) 修复登录超时 - 来源:a1b2c3d。原始修复提交写 [BUG-1024] 修复(release/2.3) 修复登录超时，不填来源。格式不必追求工具强制校验，但需要在团队内固定下来并写入提交模板。
缺陷单内维护提交清单
在缺陷单中增加一张提交清单，每条提交一行，字段设计如下：
| 字段 | 填写内容 | 填写人 |
|---|---|---|
| 仓库 | 提交所在代码库名称，多仓库时用于分组 | 提交人 |
| 分支 | 提交落入的目标分支 | 提交人 |
| 提交哈希 | 完整或足够区分的前缀哈希 | 提交人 |
| 提交类型 | 修复 / cherry-pick / 回合并 | 提交人 |
| 来源提交 | cherry-pick 或回合并时填写源提交哈希，原始修复留空 | 提交人 |
| 状态 | 已合入 / 待合入 / 已回合并 | 评审人 |
| 验证结果 | 通过 / 未通过 / 待验证，附验证环境或版本 | 验证人 |
清单的追加规则要明确：cherry-pick 和回合并产生的新提交作为独立条目追加，不覆盖、不合并原条目，来源提交字段指向被复制或被回退的那条提交。这样即使同一修复在五条分支上存在，缺陷单里就有五条记录，每条都能看出它是原始修复还是派生提交。
多仓库按仓库分组
同一缺陷涉及多个仓库时，提交清单按仓库分组展示，每组内再按分支排列。汇总视图以缺陷单为入口，不要求把所有提交塞进一行。跨仓库的修复顺序（例如先改后端接口再改前端调用）可以在缺陷单描述中写一句依赖说明，清单本身只记录提交事实。
角色分工
提交人负责在提交时写规范信息，并在缺陷单中登记仓库、分支、哈希、类型与来源；评审人负责在合并评审时核对清单条目与实际提交是否一致，并把状态更新为已合入或已回合并；验证人负责在目标分支验证后填写验证结果与验证环境。三方各管一段，避免清单由一人维护而失真。
缺陷单要承载这张可编辑的清单，需要工作项支持扩展字段或子表记录。ONES Project 适配缺陷管理等场景，支持缺陷跟踪与状态统计，可作为缺陷单与提交清单的承载位置；清单中的哈希、分支等字段的具体配置方式，以团队实际可用的工作项字段能力为准。
适用前提与代价
这套做法成立有两个前提。一是提交信息规范能被团队稳定执行，包括提交模板、评审时的检查动作，以及新成员入职时的说明；规范靠自觉维持时，通常在两三周内就会松动。二是缺陷单可以扩展字段或附加子表，用来存放提交清单，并且提交人、评审人、验证人都能编辑各自负责的字段。
代价主要在提交和合并两个时点。提交时每条提交多写分支、类型、来源三项信息，按一条提交多花半分钟估算，一个中等规模迭代的额外投入可以接受；合并与 cherry-pick 时需要在缺陷单追加条目，分支越多追加次数越多。阻力通常来自节奏快的团队：发布前集中 cherry-pick 十几条提交，容易漏记。应对方式是在固定检查点核对，例如每日站会前由评审人扫一遍当日合入提交，发布分支创建后做一次清单完整性检查。
也有不适合直接套用的情形。一次性热修、事后不保留缺陷单的紧急处置，登记清单的成本高于收益，可以只保留提交信息中的缺陷号。尚未建立缺陷单流程的团队，应先有缺陷记录，再谈提交清单，否则清单没有挂载对象。
效果验证：怎么判断关联真的可核对
验证的目标是确认“缺陷到提交”和“提交到缺陷”两个方向都能核对，而不是证明缺陷因此变少。建议用抽样核对加指标统计两种方式。
抽样方法：每周随机抽取一定数量的已关闭或已验证缺陷单，通常十到二十个足够观察问题，逐个比对清单条目与实际分支提交记录。核对三件事：清单中的哈希在对应分支上是否存在；分支上带该缺陷号的提交是否都出现在清单中；cherry-pick 与回合并条目是否填写了来源提交。发现不一致时记录差异类型，不急于归因到个人。
可观察指标建议统一口径：
| 指标 | 计算方式 | 观察意义 |
|---|---|---|
| 关联缺失率 | 抽样缺陷中，存在未登记提交的缺陷数 ÷ 抽样缺陷数 | 反映清单覆盖是否完整 |
| 回合并未记录数 | 抽样范围内，实际发生回合并但清单无对应条目的次数 | 反映派生提交的追加规则是否被执行 |
| 验证结果空缺数 | 清单中状态为已合入但验证结果为空白的条目数 | 反映验证环节是否闭环 |
验证节奏可以跟随迭代：每个迭代结束做一次抽样，由质量或测试负责人牵头，评审人提供合并记录作为比对依据。连续两到三个迭代关联缺失率下降并稳定在较低水平，可以认为改进生效；如果指标没有变化，先检查抽样是否覆盖了多分支缺陷，再检查提交模板是否真的被使用。
结果解读需要保留限制。样本量小时，单次抽样的波动可能大于真实变化，不宜用一次结果下结论；分支策略调整（例如从多分支维护改为主干开发）会改变提交分布，前后指标不具备直接可比性；关联缺失率下降也可能来自提交量减少，需要结合提交总数一起看。把这些限制写进验证记录，结论才站得住。
常见问题
同一缺陷在开发分支和发布分支各有一条提交，缺陷单里应该登记几条？
按提交事实登记，两条提交就登记两条。每条记录分别填写仓库、分支、提交哈希、提交类型与状态，发布分支上的那条如果是 cherry-pick 来的，还要在来源提交字段填写开发分支上的原始哈希。这样从缺陷单能看出修复覆盖了哪些分支，也能看出哪条是原始修复、哪条是派生提交。合并成一条记录会丢失分支维度和来源关系，后续核对时无法判断发布分支是否真的带上了修复。
cherry-pick 之后又对目标分支做了回合并，清单怎么记才不会乱？
回合并同样产生新提交，按追加规则再记一条，类型选“回合并”，来源提交填被回退的那条提交哈希。原 cherry-pick 条目保留，状态改为“已回合并”，不要删除。这样清单上能读出完整过程：原始修复、复制到目标分支、在目标分支被回退。如果只保留最新状态而删掉中间条目，事后排查“这条分支为什么没有修复”时就缺少依据。
团队分支多、发布节奏快，清单经常漏记，有什么低成本的补救办法？
先设固定检查点，把核对动作挂到已有节奏上：每日站会前由评审人扫一遍当日合入提交，发布分支创建后做一次清单完整性检查。检查范围只覆盖当天或本次发布涉及的缺陷，不要求全量回查。另一个办法是缩小必填范围，分支、哈希、类型、来源四项必填，验证结果允许先留空、验证后再补。漏记严重的团队可以先在一个迭代内只对发布分支的 cherry-pick 强制登记，稳定后再扩展到全部分支。
缺陷单里的提交清单，用工作项字段还是单独建一张表？
取决于缺陷单所在系统能提供什么。工作项支持子表或多行扩展字段时，直接挂在缺陷单下最省事，提交人、评审人、验证人各自编辑负责的列，权限和状态流转沿用缺陷单本身。只能加单值字段时，可以先用“相关提交”文本字段按行记录，格式固定为“仓库|分支|哈希|类型|来源|状态|验证结果”，再靠抽样核对保证格式一致。ONES Project 适配缺陷管理等场景，支持缺陷跟踪与状态统计，可作为缺陷单的承载位置；清单字段的具体配置方式以团队实际可用的工作项字段能力为准。
抽样核对发现关联缺失率没有下降，应该先查什么？
按顺序排查三件事。先看抽样是否覆盖了多分支缺陷，如果样本集中在单分支修复上，指标本来就反映不出问题。再看提交模板是否真的被使用，抽查近期提交信息里分支和来源字段的填写比例。最后看检查点是否在执行，合并评审时有没有人核对清单条目。三项都正常而指标仍无变化时，考虑分支策略是否调整过，前后提交分布不同会让指标失去可比性，此时应重新设定基线再观察两到三个迭代。
