彭河森谁还没在Git里翻过车呢。去年做一个预约小程序，上线前最后一天发现支付回调的验签逻辑写错了，而那个提交是前一天刚推上去的，同事还在那个版本基础上加了日志埋点。我当时脑子里只有 git reset --hard 一个念头，要不是动手前多问了一句，差点把同事的提交一起卷进回退，酿成一次线上事故。
那次之后，我把 Git 里“回退版本”这件事彻底捋了一遍，发现 90% 的混乱都来自三个命令被混着用：git reset、git revert、git restore。用圈里的话说，这三个就是“git回退版本三兄弟”。这篇不打算写成命令字典，而是按“什么时候用谁、用完有什么后果、出了事怎么救”来聊，适合刚学会 add/commit、正被回退操作折腾得睡不着的新手，也适合工作里经常手滑、想彻底理顺思路的中级用户。
1. 三兄弟到底管的是哪一段“历史”
先说一个最容易搞错的点：很多人以为回退版本就是“让代码回到过去某个状态”，所以统一用 git reset。这是最大的误区。三兄弟虽然都叫“回退”，但操作对象完全不一样，用错了后果天差地别。
1.1 一次让我冒冷汗的回退事故
先还原一下我那次事故现场。项目用的是 Git Flow，main 分支合入后大家都在上面继续开发。我的支付回调提交 3f9c21a 已经合进了 main，同事在其后做了一个 7a4d2b1 的埋点提交。
当时我的第一反应是 git reset --hard 3f9c21a——把 main 退回到我提交之前，这样有问题的支付回调就“消失”了，看起来一切正常。但问题在于，同事的 7a4d2b1 是在我提交之后才产生的，reset 会让同事的提交也从分支历史上消失。如果同事已经把这个提交推到了远程，他的本地历史就和远程直接分叉，后面合代码全是幺蛾子。
这就是三兄弟最核心的区别：reset 回退的是“整个版本历史”，revert 回退的是“某一次提交的内容”，restore 回退的是“个别文件的内容”。三者操作对象不同，后果完全不同。
1.2 reset、revert、restore 的本质分工
三个命令的本质可以这样概括：
git reset：移动当前分支的 HEAD 指针到指定提交，分支历史从那个提交之后被“抹掉”。它只操作本地仓库，不会直接影响远程，直到你执行git push或者git push -f。git revert：不移动指针，而是针对某个提交做一次“反向修改”，生成一个全新的提交来抵消旧提交的改动。历史完整保留，只是多了一个“撤销提交”。git restore：既不移动指针，也不产生新提交，只把工作区或暂存区里的某些文件恢复到指定版本。
用一张表把它们的差异摆出来，比记十遍概念都管用：
| 命令 | 操作对象 | 是否改写历史 | 是否产生新提交 | 典型场景 |
|---|---|---|---|---|
git reset |
HEAD 指针 + 暂存区 + 工作区 | 是 | 否 | 本地还没 push 的提交，想整体回退 |
git revert |
某个提交的内容 | 否 | 是 | 代码已经 push 到共享分支 |
git restore |
文件内容 | 否 | 否 | 丢弃某个文件的修改，或从历史恢复文件 |
1.3 一个比喻帮你记住差异
我后来跟组里新人讲这三个命令，都是用电视剧剪辑室做类比。
reset是把剪辑时间线直接拖回某一集重新剪，后面剪好的集数全部作废，设定全改。revert是在现有时间线后面补拍一集“反转剧情”，把之前某集里埋错的线在剧情里圆回来，前面的剧集原封不动。restore则是只替换某一帧的画面，比如把第三集第 12 分钟的背景颜色改掉，不动时间线，也不动其他集。
这个类比很糙，但能把“指针、提交、文件”这三个层次分清楚。你每次想回退之前，先问自己一句：“我要改的是指针、是提交，还是文件？”答案一出，命令基本就定下来了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. git reset：本地未推送时的“后悔药”
reset 是收尾最彻底、也最危险的一个。它能反悔的范围很广，能反悔 commit、能反悔 add、还能连带着把工作区改动一起销毁。
2.1 --soft、--mixed、--hard 三个档位到底改了啥
reset 命令最常见的形态是后面跟一个提交点，外面套一个档位参数。我直接说结论，三个