工作流
让 AI 拟一次公开提交回退，并验证数据兼容
用反向提交保留历史，同时确认数据和发布步骤。
资料核验2026.11.12 · Git · 已有版本历史的项目
一个新筛选条件已经合并，结果把旧订单从列表里隐藏了。如果改动有独立提交，先看它是否可以用 revert 回退。Git 会创建一个新的反向提交，其他协作者仍可沿用现有分支历史。
交给编码助手的任务
给助手发布提交、已应用迁移清单和一个历史订单样本。让它只在临时分支提出回退，先区分纯代码与结构变化，交付反向差异和验证结果。合并提交的主线父提交由维护者结合历史确认。
回退前看提交边界
先看这个提交里有没有顺手加进去的字段或迁移。纯查询变更可以在临时分支执行 git revert <commit>，然后用一组包含旧订单的测试验证。合并提交需要明确主线父提交，别让助手猜哪个编号。
如果数据库已经迁移，代码回退后可能仍面对新结构。验证旧代码能读新数据，并确认实际环境是否已经重新部署。
发布记录里写清被撤回的提交和修复的用户症状，下一次再做同一功能时就有线索。
先准备一个对照样例
以「新筛选隐藏了已关闭订单」为故障，准备三条订单及其期望可见性。请助手在回退前后分别运行查询，并确认新加的数据字段仍能被旧代码读取。若发布流程未运行，回退提交只改变仓库状态。
用这些结果验收
- 旧订单重新出现在列表。
- 当前结构能被回退后的代码读取。
- 部署记录指向实际回退版本。
审查时容易漏掉什么
如果反向提交会撤掉一起混入的无关修复，先把差异拆开核对，再决定是否更适合做定向修复。数据库的回滚属于另一件事，不能从 Git 的退出码推断数据已经恢复。
上线回退前，请助手在差异之外给一份用户动作清单，例如列表查询、旧订单详情、导出。分别用旧数据和上线后产生的新数据检查。若有写入规则变化，记录回退后的行为是否仍能处理新记录，避免只看旧样本。
