Tianyi Cui
2.0 KiB
2.0 KiB
Agent Note: 增量更新 PR 的 base 分支
Status: implemented
English | 中文
问题
将 PR（Pull Request）的 base 分支当前顶端提交合入 PR 分支的过程中，base 分支可能继续前移。若改从新的顶端提交重新开始，就会丢弃已经完成的冲突解决和验证工作。重写已经推送的合并还会抹去可供评审的历史记录。
决策
选择 merge-forward 时，每次观察到的 base 分支顶端提交都保留为独立的合并检查点。如果处理期间 base 分支继续前移，先完成并验证正在进行的合并，再将其提交；任务授权推送时，还要完成推送。完成这些步骤后，才能拉取较新的 base，并通过单独的合并提交将其合入。在这条 merge-forward 序列中，不得放弃或重写任何检查点。
原生堆叠与可选 rebase 决策也允许独立或堆叠 PR 使用受 lease 保护的 rebase，评审后同样如此。本文只负责 merge-forward 路径。堆叠 PR 落地 skill（技能）根据根 AGENTS.md 选择其中一种历史更新方式，堆叠评审指南则负责说明如何在依赖层之间传播修复。
曾考虑的替代方案
中止当前工作，改从最新 base 重新开始。 这会丢弃已经解决的冲突和完成的验证，重复劳动，并失去一个有用的恢复点。
重写为一次同时包含两个 base 分支顶端的合并。 这会掩盖冲突解决的顺序；如果第一次合并已经推送，还必须重写远程历史。
后果
- PR 的 base 多次前移时，这个 PR 可以包含多个用于合并 base 的提交。
- 已完成的工作不会被丢弃，而是保持可供评审和恢复。
- 合入较新的 base 会改变合并后的文件树，因此相关检查会在下一次推送前重新运行。