发布后多维护线回移策略

最典型的场景是：线上某个 bug 修好了，但你同时还维护多个已发布版本。
这时问题不只是“回不回移”，而是：

• 哪些维护线真的需要这个修复
• 应该先回哪条线
• 每条线是否能承受同一种修复表达
• 如何记录哪些版本已经带修复

先确认

受影响版本维护分支优先级修复依赖

→select → backport → verify

最终得到

维护线状态清楚修复范围可追踪版本说明完整

多线回移的难点通常不在命令，而在选择和验证。

这个工作流解决什么问题

一个修复在主线成立，不代表它应该自动进入所有维护线。
维护分支之间常常已经分化：

• 依赖版本不同
• 配置状态不同
• 代码结构不同
• 风险接受度不同

所以回移的核心，不是“一次 pick 成功”，而是“这条线到底需不需要、适不适合、怎么验证”。

更稳的处理顺序

1. 先确认修复影响哪些已发布版本

不要默认“所有仍在维护的版本都要补”。
先判断：

• 哪些版本真的会触发这个问题
• 哪些版本的风险高于回移成本
• 哪些版本已经接近停止维护

2. 再排维护线优先级

通常更稳的顺序是：

• 先最接近主线的一条维护线
• 再往更旧的分支逐步回移

因为越接近主线，代码上下文通常越接近原始修复，也更容易判断真正差异。

3. 逐条回移并逐条验证

不要一次性“全搬过去”。
每条线都应该单独检查：

• cherry-pick 是否干净
• 依赖和配置是否仍然适用
• 测试和运行验证是否通过

4. 明确记录哪些线已经完成，哪些线被跳过

多线维护最大的隐藏成本之一，是过几天之后已经没人能说清：

• 哪些版本有修复
• 哪些版本没有
• 哪些版本是故意不补

所以记录本身就是工作流的一部分。

为什么不能“一次性全搬”

因为不同维护线的上下文往往早就分化了。
同一个修复，在不同线上可能出现：

• 代码位置变了
• 依赖接口不同
• 配置行为不同
• 风险收益比不同

backport 的难点不是把提交搬过去，而是判断这个提交在那条线上还是否表达同一个意图。

cherry-pick 在这里为什么常见，但不能盲用

cherry-pick 很适合多线回移，因为它能把单个修复有选择地带过去。
但它不该被当成“成功执行就等于成功回移”。

更稳的理解是：

• 命令成功只是第一层
• 语义是否仍然正确是第二层
• 维护线是否真的需要它是更上层

一个适合团队执行的最小回移规则

1. 每个修复先确认适用版本范围
2. 回移按维护线优先级逐条进行
3. 每条线单独验证，不共享“已验证”的结论
4. 记录已完成、已拒绝和待处理的维护线
5. release note / changelog / support 说明同步更新

常见误区

以为一个 cherry-pick 成功就代表所有线都能直接复用

这是最常见的误解。
提交能落地，不代表修复语义完全一致。

不先排优先级，导致多线回移顺序混乱

这样很容易把最难的维护线先碰上，结果团队失去节奏。

修完后没有记录哪些版本已带修复

这会直接影响 support、release note 和后续事故沟通。

→做多线 backport 前先确认 4 件事

1. 哪些维护线真的还需要这个修复？
2. 最接近主线的维护线是哪一条？
3. 修复有没有依赖新的配置、接口或上下文？
4. 修完后，版本说明要怎么同步记录？

接下来建议继续学什么

1. Backport with cherry-pick
2. Release branch workflow
3. Hotfix and urgent fixes