Vibe Coding Git 失败恢复：先 Revert 公共影响，再用 Reflog 找回本地对象

Agent 执行完一串编辑后，“回到之前”可能指三件完全不同的事：撤销已经被同事拉取的坏提交；找回本地 reset、amend 或删分支前仍存在的提交；恢复从未进入 Git 对象或任何备份的工作树内容。把三者都回答成 git reset --hard，会把一次可控故障升级成历史改写和二次丢失。

Git 高级工作流介绍 reflog、rebase、cherry-pick 等工具用法；本文的搜索意图是事故运行手册：先保护证据，再选择最小影响的恢复机制。若仍在定位哪次提交引入回归，先走Git Bisect 回归隔离，不要在嫌疑未定时批量撤销。

第一步永远是停止扩大现场

暂停 push、合并、自动格式化、垃圾回收和并行 Agent 写入，记录仓库身份、当前 HEAD、分支、完整 status、远端跟踪状态、正在进行的 merge/rebase/cherry-pick，以及事故发生前后已执行命令。敏感输出只保存摘要。此时不要运行会移动引用或清理工作树的“探测命令”。

建立事件编号和恢复检查点，把当前坏状态也保存为可检查证据。恢复不是尽快让目录看起来正常，而是保留回答“丢了什么、谁已受到影响、恢复后是否等价”的能力。

然后分类：

共享历史优先追加 Revert

git revert 为指定提交记录反向变化，保留原提交和后续事实，适合已经被他人基于的历史。执行前逐个检查目标提交、它之后的依赖和预期反向 diff；“坏提交”可能还包含正确迁移或安全修复，整份反转会制造新事故。必要时先做针对性修复提交，而不是机械 revert。

撤销 merge commit 还需要明确主线父提交，其含义会影响 Git 对未来合并的判断，不能让 AI 根据 parent 1 的常见示例自动选择。多个提交也要按依赖设计顺序并逐步验证。revert 冲突进入合并冲突语义对账，不能用整文件 ours/theirs 快速通过。

反向代码不等于反向世界：已执行数据库迁移、发送邮件、扣费、发布包和泄露秘密都需要各自补偿或轮换。恢复收据要分开记录 Git 结果与外部结果，不能因主分支重新变绿就关闭事件。

Reflog 用来定位，不是让 Reset 变得无害

reflog 记录本地引用的更新，常能找到 amend、reset、rebase 或分支删除前的对象。它不是远端共享审计日志，也不是永久备份；复制仓库、过期策略和对象清理都会影响可用性。先只读查看相关 ref 的日志，用操作时间、旧新对象和提交内容交叉确认目标，不能只凭 HEAD@{1} 这个相对位置猜测。

找到候选对象后，优先创建一个隔离的恢复引用或在隔离 clone 中检出，使对象继续可达；先 show、比较 tree、运行最小测试，再决定怎样把内容带回当前分支。直接把活跃分支 hard reset 到候选对象，会同时改动 index 与工作树，并可能丢掉事故后的合法工作，因此不应是第一步。创建引用、切分支或修改共享历史仍要符合仓库政策和用户授权。

如果丢失内容从未提交，reflog 可能完全没有它。某些已暂存 blob 偶尔还能从未引用对象中找到，也不能把偶然可恢复性写成承诺。此时检查 IDE 本地历史、文件系统快照、受控补丁、备份或同事副本；先复制现场再尝试恢复工具。对秘密文件和用户数据，恢复过程仍受访问与保留政策约束。

用原失败场景验收恢复

恢复后至少验证四件事：目标文件和对象与预期相符；触发事故的最小场景不再失败；被撤销提交之外的行为仍通过；工作树没有新增无法解释的变化。再检查原子提交边界，让恢复结果保持可审阅，不要把事故期间所有试错压成一份补丁。

事件关闭记录包括事故类别、首个有害动作、实际受影响范围、采用和拒绝的恢复方式、Git 与外部副作用结果、验证对象，以及应新增的仓库规则或测试。不要删除失败分支、reflog 线索和运行日志来“收拾干净”，应按批准的保留期处理。

Vibe Coding 恢复能力的关键不是记住一条万能命令，而是先判断历史是否已共享、目标对象是否曾被 Git 记录、外部世界是否已经变化。Revert 保护公共历史的连续性，Reflog 帮助定位本地引用过去的位置；两者都必须在证据冻结和复验之中使用，才不会让第二次操作比第一次故障更危险。