共享分支上的合并出了问题，用revert撤回以后，功能分支仍在。再次合并却提示“Already up to date”，或者只带回修正而没有带回原功能。这时要检查的既有文件内容，也有提交之间的祖先关系。
本文给已经会提交、合并代码的开发者一套完整练习：撤回一次合并，观察原分支重试、后续修正冲突，再比较两条重新引入功能的路径。实验只有三份合成文本，不涉及实际服务或部署。实测环境为macOS、Python 3.14.4、Git 2.50.1（Apple Git-155）。
下载实验包：运行器、逐条命令记录与结果（ZIP）。需要Python 3.11+、Git 2.28+；解压进入merge-revert-lab后执行python3 run_lab.py。运行器只在自己创建的临时目录里工作，不读取现有项目、不联网、不推送，结束后清理练习目录。输出JSON含命令、返回码、提交图和检查结果；标签稳定，提交ID会随运行时间改变。
先弄清合并的两个父提交
初始提交A只有base.txt。从A分出的feature提交B新增feature.txt，内容为mode=unsafe；main上的C新增main.txt，内容为main-only。main合并feature得到M，父提交按顺序为C、B。
主分支：A → C → M
功能分支：A → B → M
M 的父提交顺序：C、Bunsafe、safe只是演示用文本，没有调用检测程序，也不表示验证了真实代码安全性。运行器用git rev-list --parents -n 1 M核对父提交顺序，才执行撤回。mainline编号指父提交位置，不能由分支名称猜测。
| 本次操作 | feature.txt | main.txt | 本例含义 |
|---|---|---|---|
| 在M执行revert -m 1 M | 删除 | 保留 | 撤销相对C引入的变化 |
| 另建分支，在M执行revert -m 2 M | 保留 | 删除 | 撤销相对B引入的变化 |
第二行也是一次成功的Git操作，却撤掉了我们想保留的main变更。退出码为0不能替代父提交核对。本例第一行生成撤回提交W，并确认W和C的tree对象相同；这个结果依赖M之后没有额外提交，真实仓库不能据此认定撤回总会回到某个历史快照。
实际处理前，在干净的审查分支核对以下内容。这里M要换成已经确认的合并提交ID，不是照抄的命令参数：
git status --short
git show --no-patch --format='%H %P' M
git diff --stat M^1 M
git diff M^1 M确认第一父提交确实对应想保留的一侧，再考虑git revert -m 1 M。如果工作区有未提交内容，先保存并核对范围；若出现冲突，审查后才能继续，不能用选择某一侧的选项跳过业务判断。
文件消失了，B仍然是祖先
W之后feature.txt不存在，但运行器执行git merge-base --is-ancestor B HEAD仍返回0：B仍在当前历史里。此时feature还停在B，再执行merge，实际输出Already up to date，HEAD未变，也没有重新创建feature.txt。
这是本次实验最需要同时保存的两条证据：文件确实被撤掉了，B也确实已经合入过。Git没有把“树中缺少某个文件”当作重新播放旧提交的理由。若只看文件目录，很容易误以为合并命令失灵。
在原功能分支上修正，直接合并会怎样
接下来在feature上新增D，把feature.txt改成mode=safe。main仍停在W，再次合并feature。本次真实结果是modify/delete冲突，git status --short出现DU feature.txt，命令退出1。
原因可以对着文件检查：B中有这份文件，main的W把它删除，feature的D却修改它。Git不能替我们决定这是“主分支有意删除”还是“现在应该恢复”。本例不是所有重新合并都会冲突的证明；如果D改的是其他文件，表现可能不同，但旧功能也不会因此自动完整恢复。
运行器没有接受任意一侧，而是执行git merge --abort，再确认HEAD回到W、工作区干净。真实仓库若在合并开始前就有未提交修改，abort不应当作完整备份承诺。本练习从干净状态开始；遇到不同状态，先保留现场再处理。
原历史继续修补：先恢复，再合入修正
第一条恢复路径适用于本例这种“B还在原分支上，D只是继续修正”的结构。我们在W上撤回W，得到Y，再合并feature得到N：
git revert --no-edit W
git merge --no-ff feature -m N| 阶段 | feature.txt实测内容 | main.txt |
|---|---|---|
| W | 不存在 | main-only |
| Y：撤回W | mode=unsafe | main-only |
| N：合并D | mode=safe | main-only |
中间的Y会重新引入旧版本，不能把Y单独当作修复完成的发布点。在真实项目中应在审查分支完成整条恢复及修正，再验证最终差异和业务测试，避免自动部署在中间提交触发。本文没有连接CI/CD，不提供部署系统的原子性保证。
W是普通撤回提交，所以撤回W时本例不加-m；不要因为原始M是合并提交，就把同一个命令选项机械带到所有后续操作。若W之后还有其他变化，撤回W或合并D都可能冲突，需要逐项解释。
从撤回后的基线重做：不要再盲目撤回W
第二条路径从W新建rebuilt分支，直接新增内容已修正的feature.txt，提交E。另建同样从W出发的目标分支，合并rebuilt。实验确认最终tree与上一条路径的N完全相同：base.txt、main.txt和mode=safe都在。
这次E本身已经包含需要重新引入的完整内容，不依赖恢复B。我们没有先撤回W；否则可能把旧实现一起拉回来，增加重叠修改。能否采用这条路径，要核对新提交是否确实重建了全部需要的功能，而不是只把旧分支最后一个修正挑过来。
| 候选分支形态 | 本例采用的路径 | 必须核对的内容 |
|---|---|---|
| 保留B，在其上追加D | 撤回W，再合并D | 恢复的旧内容与最终修正一并验收 |
| 从W出发，E重新实现完整变化 | 直接合并E | E相对W的差异确实完整 |
两条路径得到同一份文件树，不代表提交历史相同，也不代表真实应用必然行为一致。本实验的比对对象是普通文本文件及Git对象，未覆盖构建产物、数据库迁移、外部资源和部署状态。
把演练结论用到真实仓库
先记录M、父提交、W及待合入分支的完整ID，确认团队希望撤回的是整次合并还是其中一项变更。若只需修正少量代码，整批撤回会同时移除正常功能，还会让后续定位跨过一个大变化，应先评估局部修正是否更合适。
需要重新引入时，在独立审查分支完成选定路径。对比最终版本与当前主分支，检查撤回范围是否全都应当恢复；运行真实业务回归，而不只检查“merge没有报错”。本包保存了每一步返回码和内容断言，可以作为如何记录证据的示例，不能代替项目自己的测试。
本轮验证了父提交选错、重复合并无操作、modify/delete冲突及abort、两种恢复路径。没有测试远程保护分支、多人并发推送、签名规则、子模块、LFS或Windows；强制杀死运行器或掉电也不保证临时目录被清理。包采用MIT许可，SHA-256为278e7db163534b178e40de09682001ac648f27c9f6442db0d91351007ff8fa0b。
命令语义参考Git官方revert文档，两类历史的处理依据见Git项目的错误合并撤回指南；上面的合成仓库、执行记录和对照表由本站制作。封面复用浅色分支与文件恢复概念图，非终端截图。
相关旧稿：用bisect定位首次回归及无法判断的提交、保留stash暂存状态并隔离冲突现场、restore修改工作区还是暂存区。它们分别解决回归定位、未提交内容保存和文件恢复；本文处理已进入共享历史的合并撤回与再次引入。
资料查阅与编辑日期：2026年11月10日。作者：玖柒。
