小理同学几乎每个用Git的人都会遇到这种时刻——辛辛苦苦写了几天的代码，一条命令下去全乱了；或者手一抖把不该提交的提交上去了；又或者reset选错了模式，眼睁睁看着自己的工作成果消失。很多人一慌就上网搜“git 代码提交还原”，搜出来的命令一大堆，但不知道哪个适合自己当下的场景，试错之后往往损失更大。
这篇博文我想把Git还原的完整地图讲透：从工作区、暂存区、本地仓库到远程仓库，每一层状态对应哪些还原命令，背后的执行逻辑是什么，哪些操作能反悔、哪些操作只能靠辅助手段抢救。顺便把“git安装及配置教程”“git免密”这类新手高频需求也一起覆盖到，毕竟环境没搭好，后面所有操作都容易出幺蛾子。内容适合刚入门但被提交搞懵的新人，也适合已经工作一两年、没系统整理过Git还原知识点的同学。
1. 把“还原”说清楚：Git里其实有三种完全不同的后悔药
1.1 四个区域的坐标图，先别急着敲命令
网上一搜“git 代码提交还原”，出来的命令五花八门，根因是大家没说清楚自己处在哪个状态。Git的数据流动其实是一条流水线：工作区（Working Directory）——暂存区（Staging Area/Index）——本地仓库（Local Repository）——远程仓库（Remote Repository）。
用生活化的说法：工作区是你的办公桌，代码文件摊在上面；暂存区是整理好的文件盒，你打算归档但还没归档；本地仓库是档案柜，提交动作就是“把文件盒里的内容扫描进档案柜”；远程仓库是总公司的档案室，推送动作才是“把档案柜的复印件寄到总公司”。
理解了这条线，再来看“还原”，你就会发现它至少包含三种操作：把办公桌上的内容揉掉重做、把档案柜里的某格档案抽出来换掉、或者直接在档案里追加一张“更正说明”。三种操作对应的命令体系完全不同，用错就是悲剧。
1.2 reset、revert、restore的定位差异
很多初学者分不清这几个长得像的词，我直接说结论：
git restore系列：只管工作区和暂存区，不产生提交，不影响历史。git reset系列：把当前分支的HEAD指针往回拨，属于改写本地历史。git revert系列：通过新增一笔“反向提交”来抵消旧提交的改动，不改写历史。
| 命令族 | 是否改写历史 | 主要适用场景 | 对已推送分支的影响 |
|---|---|---|---|
| git restore / checkout | 否 | 丢弃未提交修改 | 无 |
| git reset | 是（改写本地历史） | 撤销本地提交 | 会让远端历史分叉 |
| git revert | 否（新增反向提交） | 撤销已推送的提交 | 安全，适合协作分支 |
记住这张表，后面所有章节都是围绕它展开的。接下来我按状态阶段逐个拆解。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 未提交就后悔：工作区与暂存区的挽回技巧
2.1 工作区改乱了，怎么回到上个版本
最典型的情况：你改了一个文件，改到一半发现思路错了，想直接丢掉这次修改，回到上次提交时的样子。这个操作不碰历史，也不碰暂存区，命令行就一句：
bash复制git restore filename
老版本习惯写法是：
bash复制git checkout -- filename
两者的效果完全一致。如果你想丢掉整个工作区的所有修改，把文件名换成点号：
bash复制git restore .
这里有个很容易踩的坑：git checkout -- . 和切换分支的 git checkout branchName 长得太像了。我见过有人想丢弃修改，结果输成了 git checkout main，不仅没丢弃，还把自己带到了别的分支。所以Git 2.23之后官方才把命令拆成 git switch 负责切分支、git restore 负责还原文件，目的就是让语义清晰。新项目我建议团队统一用新的命令族，减少误触。
还要特别提醒：git restore 丢弃的是工作区里的改动，这些改动还没有进入Git对象库，所以一旦执行是找不回的，reflog也救不了你。我的习惯是：改动量比较大、又暂时不确定要不要保留时，先别急着restore，用后面说的 git stash 存起来，至少留个后悔的余地。
2.2 已经 add 进暂存区了，想撤回来
如果你的文件已经 git add 过，工作区的修改和暂存区都处于“新增/修改待提交”状态，此时