Claude Code 写代码翻车了？Git 回滚与故障恢复实战

前言

前两篇文章里，我们搭好了 Claude Code + GitHub + Vercel 的协作环境，也学会了用 Claude Code 自动化管理项目。但你迟早会遇到一个问题——AI 翻车了。

可能是 Claude Code 批量改文件时误删了几篇博客，可能是改错了配置文件导致 Vercel 部署失败，也可能是推送了一段有 bug 的代码把线上页面搞崩了。

别慌。这就是 Git 存在的意义——它是你的时间机器，让你随时可以回到”还没出问题”的那个时刻。

这篇文章专门讲：当 Claude Code 搞砸事情的时候，怎么用 Git 把局面救回来。

AI 翻车的常见场景

先看看 Claude Code 可能怎么”翻车”，心里有个数：

翻车类型	具体表现	严重程度
误删文件	批量操作时删掉了不该删的文件	🔴 高
改错配置	修改了 _config.yml 导致构建失败	🟡 中
推送 bug	推送了有语法错误的代码，Vercel 部署失败	🟡 中
覆盖内容	用错误内容覆盖了重要文件	🔴 高
批量改坏	批量替换时正则写错，所有文件都被改错	🔴 高

好消息是：只要这些改动已经提交到了 Git，就都能救回来。哪怕文件被删了、内容被覆盖了，Git 都有办法恢复。

Git 核心概念速补

在学回滚之前，需要先理解 Git 的几个关键区域。不用背，理解意思就行：

工作区（Working Directory）  →  你电脑上看到的文件
       ↓  git add
暂存区（Staging Area）      →  准备好要提交的改动
       ↓  git commit
本地仓库（Repository）      →  提交历史，每个 commit 是一个快照
       ↓  git push
远程仓库（Remote）          →  GitHub 上的备份

关键认知：每次 git commit 都是给项目拍了一张”快照”。 回滚的本质就是”把文件恢复到之前某张快照的状态”。

记住这个概念，后面的操作就很好理解了。

回滚实战：五招救命

第一招：git checkout — 撤销工作区的修改

场景：Claude Code 刚改了几个文件，你还没 git add，一看改得不对，想撤回。

# 查看当前状态，看哪些文件被改了
git status

# 撤销某个文件的修改（还没 add 的）
git checkout -- source/_posts/某篇文章.md

# 撤销所有文件的修改（还没 add 的）
git checkout -- .

这是最轻量的一招，相当于告诉 Git：”工作区里这些改动我不要了，恢复到上次 commit 的状态。”

⚠️ 注意：这个操作不可逆。撤销后，未暂存的改动就彻底丢了。如果不确定，可以先用 git stash 暂存（后面会讲）。

第二招：git reset — 撤回暂存区或提交

场景一：Claude Code 已经 git add 了，但还没 git commit。

# 把暂存区的改动撤回到工作区（不会丢代码）
git reset HEAD

# 或者只撤回某个文件
git reset HEAD source/_posts/某篇文章.md

场景二：Claude Code 已经 git commit 了，但还没 git push。

# 撤回最近一次 commit，改动回到暂存区
git reset --soft HEAD~1

# 撤回最近一次 commit，改动回到工作区
git reset HEAD~1

HEAD~1 表示”往回退一个 commit”。如果是退两个就是 HEAD~2，以此类推。

--soft 和默认的区别：

参数	commit 撤回后，改动在哪
--soft	留在暂存区（相当于还没 commit）
默认（--mixed）	回到工作区（相当于还没 add）
--hard	直接丢弃，什么都不剩

⚠️ --hard 是最危险的选项，它会彻底丢弃所有改动。除非你确定那些改动完全不需要，否则不要用。

第三招：git revert — 安全地撤销已推送的提交

场景：Claude Code 改完代码已经 git push 到 GitHub 了，Vercel 也部署了，结果发现问题。

这时候不能直接 reset——因为远程仓库已经有了那个 commit，你本地 reset 后 push 会冲突。

正确做法是用 git revert：

# 查看最近的 commit 记录
git log --oneline

# 撤销最近一次 commit（生成一个新的"反向 commit"）
git revert HEAD

# 撤销指定的某次 commit
git revert abc1234

git revert 的原理是：生成一个新的 commit，内容恰好是目标 commit 的”反面”——它加了什么就删什么，它删了什么就加什么。

这样做的好处是不会改写历史，其他协作者不会受到影响。

# revert 完成后推送到远程
git push origin main

第四招：git stash — 临时保存现场

场景：你正在让 Claude Code 改一篇文章，改到一半发现另一个文件有更紧急的问题要处理。但当前改动还没完成，不想提交也不想丢掉。

# 把当前改动暂存起来
git stash

# 现在工作区是干净的，可以去处理紧急问题了
# ...处理完毕...

# 恢复之前暂存的改动
git stash pop

git stash 就像一个临时抽屉——把改动先放进去，等你忙完了再拿出来继续。

# 查看暂存了几个抽屉
git stash list

# 恢复指定的暂存
git stash pop stash@{1}

第五招：重新克隆 — 终极方案

场景：本地仓库搞得一团乱，reset 来 reset 去已经分不清状态了。

最简单粗暴的办法——删掉本地仓库，重新从 GitHub 克隆一份干净的：

# 回到上级目录
cd ..

# 删掉搞乱的本地仓库
rm -rf hexo-blog-source

# 重新克隆
git clone https://github.com/MIutopia/hexo-blog-source.git

只要 GitHub 上的代码是对的，重新克隆就能拿到一份完全干净的环境。之前的所有本地操作（stash、reset、checkout 搞乱的）统统不存在了。

💡 这不是”认输”，这是务实。当 Git 状态复杂到理不清的时候，花 5 分钟重新克隆比花 2 小时排查状态高效得多。

真实案例复盘

讲一个我实际遇到的情况，完整演示一遍恢复流程。

事故经过

我让 Claude Code 批量改写博客文章的格式。它读了几篇参考文章后，开始逐篇修改。改到一半时，我发现它把几篇文章的 frontmatter 删掉了，而且还 git add 了。

git status 输出：
modified:   source/_posts/article1.md    ← frontmatter 被删了
modified:   source/_posts/article2.md    ← 内容被覆盖了
modified:   source/_posts/article3.md    ← 正常

第一步：冷静，先别提交

看到问题后最重要的是——不要慌，不要急着 commit 或 push。只要还没 commit，一切都好办。

第二步：查看具体改了什么

git diff source/_posts/article1.md

git diff 会显示详细的改动对比，帮你判断哪些改动是好的、哪些是坏的。

第三步：选择性恢复

# article1 和 article2 改坏了，恢复到上次 commit 的状态
git checkout -- source/_posts/article1.md
git checkout -- source/_posts/article2.md

# article3 改得没问题，保留改动

第四步：确认状态

git status
# 现在只有 article3 是 modified 状态，其他都恢复了

第五步：重新让 Claude Code 修复

你：article1.md 和 article2.md 的 frontmatter 被你删掉了，
    请重新加上，格式参考 article3.md。注意不要动正文内容。

这次加了更明确的指令，Claude Code 正确修复了两篇文章。

第六步：检查后提交

# 再 diff 一次确认改动正确
git diff source/_posts/article1.md
git diff source/_posts/article2.md

# 确认没问题后提交
git add .
git commit -m "fix: 修复批量改写导致的 frontmatter 丢失"
git push origin main

整个过程大约 5 分钟。如果没有 Git，这两篇文章就彻底丢了。

防御性习惯：让翻车代价降到最低

与其事后救火，不如事前预防。以下是几个实用的防御策略：

1. 频繁提交，小步快跑

不要攒了一大堆改动才 commit。每完成一个小任务就提交一次，这样回滚的粒度更细，不会”一滚滚一大片”。

# 好的习惯
git commit -m "feat: 更新 article1 的 frontmatter"
git commit -m "feat: 更新 article2 的 frontmatter"
git commit -m "feat: 更新 article3 的 frontmatter"

# 坏的习惯
# 改了 15 个文件后才 commit 一次

2. 让 Claude Code 在提交前先确认

在 CLAUDE.md 里加一条规则：

## 注意事项
- 批量修改文件前，先改一个文件让我确认
- 确认通过后再批量执行
- 每次 commit 前，先 git diff 让我检查

这样 Claude Code 就不会”闷头大干”了。

3. 善用分支

对于不确定的大改动，先在新分支上操作：

# 创建并切换到新分支
git checkout -b refactor/article-format

# 在这个分支上随便改，改坏了也不影响 main
# ...Claude Code 在这里操作...

# 确认没问题后合并回 main
git checkout main
git merge refactor/article-format

如果分支上的改动彻底搞砸了？直接切回 main 分支，那个分支不要就行了。

4. 利用 Vercel Preview 部署

Vercel 对每个 Git 分支都会生成一个 Preview URL。你可以在推送前先在 Preview 环境验证效果，确认没问题了再合并到 main 分支触发正式部署。

main 分支 → 正式部署（production）
feature 分支 → Preview 部署（预览环境）

5. 定期备份关键配置

把 _config.yml、vercel.json 这类关键配置文件单独备份一份。即使 Git 出了问题，至少还有本地备份可以恢复。

常见问题与踩坑记录

❌ git reset –hard 后文件丢了，能恢复吗？

能，但稍微麻烦。git reflog 可以看到所有 HEAD 移动的记录，包括 reset 操作：

git reflog
# 找到 reset 之前的 commit hash
git reset --hard HEAD@{3}  # 回到那个状态

只要还没有被 Git 的垃圾回收清理掉（默认 30 天），就能找回来。

❌ 已经 push 到 GitHub 的错误 commit，revert 后需要 force push 吗？

不需要。git revert 生成的是新 commit，正常 git push 就行。只有 git reset 改写了历史才需要 force push（而且不推荐在公共分支上 force push）。

❌ Claude Code 执行 git push 后 Vercel 部署失败了，怎么办？

先查看 Vercel 的构建日志定位错误。如果是代码问题，修复后重新 push 即可——Vercel 会自动重新部署。如果急需回滚到上一个正常版本，可以用 git revert 撤销那次有问题的 commit 再 push。

❌ 多人协作时回滚会不会影响其他人？

会。如果你在公共分支上用了 git reset --hard 然后 force push，其他人的本地仓库会和远程不一致。所以公共分支上优先用 git revert，它不改写历史，对所有人都安全。

❌ git stash pop 后出现冲突怎么办？

stash 的内容和当前文件有冲突时，Git 会标记冲突区域。手动解决冲突后，运行 git add 和 git commit 完成合并。如果冲突太多不想处理，可以 git checkout -- . 放弃 stash 的改动。

总结：回滚速查表

最后整理一张速查表，遇到问题直接对照操作：

情况	命令	说明
改了文件，还没 add	git checkout -- 文件名	撤销工作区改动
已经 add，还没 commit	git reset HEAD 文件名	撤回到工作区
已经 commit，还没 push	git reset --soft HEAD~1	撤回 commit，保留改动
已经 push 到远程	git revert HEAD	生成反向 commit
想临时保存现场	git stash → git stash pop	暂存 → 恢复
彻底搞乱了	重新 git clone	从头来过

记住一个核心原则：只要代码在 Git 里，就丢不了。每次 commit 都是一个存档点，随时可以读档重来。

---

四篇文章到这里就结束了。从环境搭建到自动化管理，再到故障恢复，你已经有了一套完整的 AI 协作开发工作流。剩下的就是动手实践——打开终端，输入 claude，开始你的第一次 AI 协作吧。