Tianyi Cui
28 lines
1.8 KiB
Markdown
28 lines
1.8 KiB
Markdown
# Agent Note: 增量更新 PR 的 base 分支
|
||
|
||
Status: implemented
|
||
|
||
[English](2026-07-26-incremental-pr-base-retargeting.md) | 中文
|
||
|
||
## 问题
|
||
|
||
将 PR（Pull Request）的 base 分支当前顶端提交合入 PR 分支的过程中，base 分支可能继续前移。若改从新的顶端提交重新开始，就会丢弃已经完成的冲突解决和验证工作。重写已经推送的合并还会抹去可供评审的历史记录。
|
||
|
||
## 决策
|
||
|
||
每次观察到的 base 分支顶端提交都保留为独立的合并检查点。如果处理期间 base 分支继续前移，先完成并验证正在进行的合并，再将其提交；任务授权推送时，还要完成推送。完成这些步骤后，才能拉取较新的 base，并通过单独的合并提交将其合入。绝不放弃先前工作，也不通过 amend、rebase 或其他方式重写它。
|
||
|
||
根 [AGENTS.md](../../../../AGENTS.md) 规定了这项常设指令。[堆叠 PR 落地 skill（技能）](../../../skills/dsh-merging-stacked-prs/SKILL.md)在调整依赖 PR 的 base 时执行这一规则，[堆叠评审指南](../../../../docs/cookbook/responding-to-pr-review-on-a-stack.md)则负责说明如何将修复沿堆叠向下合并。
|
||
|
||
## 曾考虑的替代方案
|
||
|
||
**中止当前工作，改从最新 base 重新开始。** 这会丢弃已经解决的冲突和完成的验证，重复劳动，并失去一个有用的恢复点。
|
||
|
||
**重写为一次同时包含两个 base 分支顶端的合并。** 这会掩盖冲突解决的顺序；如果第一次合并已经推送，还必须重写远程历史。
|
||
|
||
## 后果
|
||
|
||
- PR 的 base 多次前移时，这个 PR 可以包含多个用于合并 base 的提交。
|
||
- 已完成的工作不会被丢弃，而是保持可供评审和恢复。
|
||
- 合入较新的 base 会改变合并后的文件树，因此相关检查会在下一次推送前重新运行。
|