modernize

现代化

现代化的是想法，而不只是分支。干净地变基并不能证明这个 PR 仍应纳入产品。

防护措施

• 开始前，务必确认已拉取与你的工作相关的分支的最新 origin、main 分支以及其他分支。
• 将现有工作树中的更改视为用户所有。如果当前工作树不干净或正在用于其他工作，请使用一次性工作树。
• 现代化授权你变基并更新 PR 分支，但不授权你合并、关闭 PR、更改基础分支或扩大范围。
• 绝不要在未指定条件的情况下强制推送。更新变基后的分支时，使用 --force-with-lease，并以变基前观察到的头部 SHA 为依据。
• 除非用户要求，否则不要发布 PR 评论。凡是代表用户发布评论，都要使用 leaving-pr-comments 技能。

明确 PR 的意图

解析 PR，并记录其 URL、状态、基础分支、头部仓库和分支、当前头部 SHA、作者、检查结果及评审状态。阅读标题、正文、关联的议题、提交、评审讨论串以及完整差异。在评判实现之前，先说明该 PR 原本试图实现的最小完整目标。

获取最新的远程基础分支和 PR 头部分支。使用 PR 实际的基础分支，通常是 main，而不要假定本地分支是最新的。记录合并基点，以便分别比较原始 PR 与后续基础分支更改。

检查周边发生的变化

检查 PR 分叉以来，基础分支上新增的提交和差异。当标题、代码路径或行为表明可能存在替代方案或竞争实现时，搜索已合并和未关闭的 PR。

不要只看重叠的代码行：

• 相同的面向用户问题是否已经解决？
• API、类型、架构、依赖项或架构边界是否发生变化？
• 双方现在是否都声称拥有相同的行为或不变量？
• 正在更改的代码是否已被删除、移动或有意简化？
• 合并该 PR 是否会恢复旧行为，或为同一功能引入两种实现方式？
• 原有收益是否仍足以抵消维护成本？

不要仅仅因为 Git 报告没有冲突，就说 PR 仍然适用。

推送前选择处理方式

从以下建议中选择一个：

• MODERNIZE：目标仍有价值，且当前实现仍是合适的方向。执行变基、解决冲突、测试并更新分支。
• REWORK：目标仍有价值，但机械变基会保留不合适的实现。说明最小可行的重写方案；除非用户也要求重做，否则在推送前停止。
• CLOSE：该 PR 已被取代、已过时、方向有误，或已不值得付出相应成本。列出具体依据并停止。不要浪费时间变基已过时的分支，也不要未经明确许可就关闭它。

要愿意建议 CLOSE。仅仅年代久远并非证据，已经投入的工作也不是继续保留 PR 的理由。

变基时保留原意

对于 MODERNIZE 处理方式：

1. 在记录的 PR 头部创建安全的本地分支或一次性工作树。
2. 将其提交变基到刚刚获取的基础分支上。
3. 根据 PR 当前的意图和基础分支中较新的不变量解决每个冲突。如果冲突表明产品或架构方向存在分歧，请停止并重新考虑处理方式，而不是猜测。
4. 使用 git range-diff 比较变基前后的提交序列，并检查最终差异。确认没有丢失任何有意实现的行为，也没有重新引入已合并的行为。
5. 对涉及的部分运行仓库中有针对性的检查。区分实际故障与已有故障或基础设施故障。
6. 使用与先前观察到的远程头部绑定的 --force-with-lease 推送。如果租约失败，请获取最新更改并重新评估，而不是覆盖新工作。

不要合并 PR。

报告

开头先写 MODERNIZE、REWORK 或 CLOSE，并说明原因。然后总结：

• 基础分支上的重要变更；
• 概念上的冲突，或确认未发现冲突；
• 已执行的变基和推送结果；
• 已运行的检查及其结果；
• 尚待作出的决定或完成的工作，并附上 PR 链接。

区分观察到的事实与判断。对于无法验证的内容，应明确说明，而不是表现得胸有成竹。