小理同学几乎每个用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 过，工作区的修改和暂存区都处于“新增/修改待提交”状态，此时想退回一步，有两个命令效果一样：
bash复制git reset HEAD filename
git restore --staged filename
执行完，文件会从暂存区回到工作区，但内容不会丢。这个操作非常安全，相当于“把文件盒里的文件拿回办公桌”，改动全部保留。
如果你希望更彻底一些：把文件从暂存区撤回来，同时把工作区的内容也恢复到上次提交的状态，可以连起来执行：
bash复制git restore --staged filename
git restore filename
两行合起来的效果等于 git reset --hard HEAD -- filename，但语义更容易理解。注意，这个操作是双重重置，没进对象库的内容照样找不回，动手前确认好。
2.3 零散文件太多？用 stash 和 clean 做兜底和清理
有些时候你不想“丢弃”修改，只想暂时把桌面收拾干净，集中处理另一件事。这时 git stash 是神器：
bash复制git stash # 暂存所有未提交修改，工作区变干净
git stash list # 查看暂存列表
git stash pop # 恢复最近一次暂存，并从列表移除
git stash apply # 恢复最近一次暂存，但保留列表记录
git stash push -m "临时保存登录模块改动" # 带说明信息
pop 与 apply 的差别是弹栈后是否保留记录。多人联调时我常用 apply，因为 pop 偶尔会遇到同文件冲突，留一条记录方便比对。
另一个清理类命令是 git clean，用于删除未被Git跟踪的文件：
bash复制git clean -nd # 先预览：哪些未跟踪文件会被删除
git clean -fd # 删除未跟踪文件和目录
注意 -f 是必须的，不加它会因为安全问题拒绝执行；-d 表示连带目录一起删。未跟踪文件一般不在Git版本管理内，删除后同样无法恢复。我建议任何 clean 操作前都先执行一遍 -nd 预览，确认清单没问题再删。
3. 提交到了本地但还没推送：reset 三档模式帮你精准撤销
3.1 soft / mixed / hard 到底差在哪
提交进本地仓库但还没 git push，此时想撤销，默认武器是 git reset。它有三档模式，核心差异在于回退后分别会保留哪些状态：
bash复制git reset --soft HEAD~1 # 只回退HEAD，暂存区保留，工作区保留
git reset --mixed HEAD~1 # 默认档，回退HEAD和暂存区，工作区保留
git reset --hard HEAD~1 # 回退HEAD、暂存区和工作区，彻底丢弃
--soft：相当于“把提交撤销掉，但add状态还在”。执行完你会有很多绿色的“已暂存”文件，可以直接重新commit。--mixed：相当于“把提交和add都撤销掉，文件变成已修改未暂存状态”。这是默认档，也就是git reset HEAD~1等同于git reset --mixed HEAD~1。--hard：提交、暂存、工作区全部回到上一个提交的状态，目标提交之后的所有改动直接消失。
给个比喻：--soft 是把档案柜里的档案抽出来放回文件盒；--mixed 是抽出来直接扔回办公桌，文件盒也清空；--hard 是抽出来当场销毁，办公桌上也恢复成旧档案的复印件。
3.2 三种场景，自己对号入座
场景一：刚提交完，发现提交信息写错了，改动本身没问题。
bash复制git commit --amend -m "正确的提交信息"
这不算reset，但它解决的是“提交后后悔”最轻度的问题。--amend 会修改最近一次提交，而不是新增一笔“改提交信息”的提交，历史更干净。
场景二：提交里混进了不该提交的大文件或密钥文件，想拆开重来。
bash复制git reset --soft HEAD~1
git reset HEAD secret.key
# 然后重新 git add 需要的文件，再 commit
--soft 在这里很关键，它保留了所有暂存状态，你只需要把不该提交的文件从暂存区剔除，其他文件可以原封不动重新提交。
场景三：整个提交都写错了，改动也没意义，想彻底丢掉。
bash复制git reset --hard HEAD~1
这是最危险的操作，因为工作区内容会跟着变。执行之前务必确认你不想保留任何相关改动。不确定性比较强的时候，退而求其次用 --mixed，至少工作区能保住东西。
3.3 回退多个提交的边界与风险
想回退多个提交，可以指定目标哈希：
bash复制git log --oneline -10 # 先看历史，找到目标提交哈希
git reset --hard abc1234 # 把当前分支直接指到 abc1234
这条命令会把 abc1234 之后的本地提交全部“摘掉”。注意，这些提交只是没有分支引用了，并没有被立即物理删除，后面第5章会讲怎么找回。
回退多个提交时，我强烈建议不要凭印象数 HEAD~5 或 HEAD~10，因为很容易数错。先 git log --oneline 确认目标哈希，再动手，习惯性把哈希前几位写全（4位以上即可，能唯一匹配就行）。
另外，如果是笔误提交了不想提交的内容，并且影响的是远程分支，那就要看下一章：已经推送的分支，reset 不是首选方案。
4. 已经推送到远端：revert 与 force push 的博弈
4.1 为什么公共分支不要随便改写历史
一旦 git push 成功，你的提交就到了远程仓库。如果此时你 reset --hard 回退，再 git push --force 强制覆盖远端，就会产生一个核心问题：其他同事如果已经基于旧提交拉取并开发了，他们的本地历史与远程会发生分叉，下次 pull 会出现莫名其妙的合并冲突或者重复提交。
打个比方，你发给全公司的文件发现有错误，直接把旧文件从档案室抽走销毁，但所有人手里都已经留了复印件。你销毁原件，大家手里的复印件不会自动变，反而会被系统认为“你们手里拿着不存在的档案”。
所以行业里针对公共分支有一条不成文规矩：历史一旦共享，就不要改写，用新增提交来纠错。这就是 git revert 存在的意义。
4.2 revert：用一个新提交抵消旧提交
最基本的用法：
bash复制git revert HEAD # 撤销最近一次提交
git revert abc1234 # 撤销某个历史提交
revert 会读取目标提交的 diff，生成一个反向 patch，然后创建一个新提交。旧提交留在历史里，新提交把它的改动抵消掉。这样所有同事pull下来后，历史的拓扑是一条线性向前推进的线，没人会感到异常。
如果需要撤销一连串提交，而且这些提交彼此有依赖关系，可以分段revert，也可以先把反向改动全部暂存再统一提交：
bash复制git revert --no-commit abc1234 def5678
git commit -m "回滚 abc1234 与 def5678 引入的问题"
--no-commit 模式会把两笔反向改动同时应用到工作区和暂存区，你可以先检查一遍再提交，避免中间提交导致冲突。这个模式下如果两个提交之间有承继关系，可能产生冲突，需要手动解决后再 git add 和 git commit。
revert 会遇到一个有意思的情况：你想撤销的提交后来又被其他提交修改了相关文件，revert 时会冲突。这时不要强行 -n 跳过，老老实实打开冲突文件，把抵消结果调整到符合语义再提交。
补充一个冷门但实用的点：如果想“撤销一次revert”，可以再 revert 那个 revert 提交。历史会表现为“提交A——反向提交B——再反向提交C”，最终业务代码回到提交A的状态，但整个路径清晰可查。
4.3 私有分支确实要 reset 强推，怎么办
场景是：你自己的功能分支、修复分支，确认没有别人基于它工作，或者你的团队足够小、能保证大家统一同步。这时可以用 reset 让本地历史干净，再强推：
bash复制git reset --hard <target-hash>
git push --force-with-lease
在这里我强烈建议用 --force-with-lease 而不是 --force。两者的差别是：--force 无条件覆盖远端；--force-with-lease 在推送前会检查远端引用是否和你本地记录的远端状态一致，如果远端被别人更新过，它就拒绝执行。
这个功能等于是给强推上一道保险，避免你把同事刚刚推上去的代码覆盖掉。我从改用 -with-lease 之后，再没在协作中闯过“覆盖别人提交”这种大祸。
强推之后，其他协作者的本地分支会与远端分叉，他们需要执行：
bash复制git fetch origin
git reset --hard origin/your-branch
注意，这一步在协作分支上要极其谨慎，因为 reset --hard 会丢弃他们本地未推送的提交。
5. 数据灾难抢救：reflog 能找回你以为丢失的提交
5.1 reflog 的底层逻辑，为什么丢的还能找回来
很多人在 git reset --hard 之后心凉半截，觉得所有提交都没了。实际上，Git 的对象库是内容寻址存储，提交对象一旦写入，不会因为分支指针移动就被立刻删除。所谓“丢弃”，只是分支不再引用它；对象仍安静地躺在 .git/objects 里，等待被 git gc 当垃圾回收。
reflog（reference log）记录的是HEAD以及分支引用在本地仓库中的每一次移动轨迹。每当你执行 commit、reset、checkout、merge、rebase 等操作，Git 都会在 .git/logs/HEAD 中追加一行记录。你完全可以把它理解为Git自己的“操作历史日志”。
默认情况下，reflog 里的内容保留期为90天（可通过配置项 gc.reflogExpire 调整）。也就是说，你在90天内搞丢的提交，基本都有机会捞回来。
5.2 找回 reset --hard 之后的提交，完整步骤
场景：你执行了 git reset --hard HEAD~1，然后发现刚才那次提交里其实有一个重要文件的修改，必须找回。
第一步，查看reflog：
bash复制git reflog
输出类似：
text复制abc1234 HEAD@{0}: reset: moving to HEAD~1
def5678 HEAD@{1}: commit: 添加了登录模块的基础逻辑
第二行 def5678 就是你把HEAD拨回去之前的那个提交。
第二步，基于该提交创建一个备份分支，确保它被强引用，不会再被GC：
bash复制git branch recover-login def5678
第三步，确认内容没问题后，可以根据情况选择合并或者直接硬切回去：
bash复制git merge recover-login # 合回当前分支
# 或者
git reset --hard recover-login # 如果你确定要整体回到那个提交
整条链路最核心的动作是第一步创建分支：一旦有了分支引用，这个提交对象就处于“安全区”，不会被垃圾回收机制清除。
5.3 误删分支、误清暂存区的恢复路径
误删分支是另一个高频事故。执行 git branch -D some-branch 之后，分支没了，上面所有提交看起来都蒸发了。恢复方法同样是借助reflog：
bash复制git reflog # 找到该分支最后一次指向的提交哈希
git branch some-branch <hash> # 从目标哈希重新拉出分支
reflog里分支的移动记录可以用 git reflog show some-branch 查看，但分支删除了之后，更稳妥的是从 HEAD 的全局reflog里找线索，因为你在那个分支上的最后一次操作（commit、merge等）一定会记录在HEAD的日志里。
如果是误操作 git reset 导致暂存区被清空，但工作区改动还在，那不需要reflog，直接重新 git add 就好。真正的“数据灾难”只发生在 --hard 或 clean -fd 之后，而这两种情况reflog都能兜住绝大多数场景。
我在实际项目里养成的习惯是：任何指向“不可逆”的操作之前，先 git reflog 截图存个底，操作完发现不对，直接按记录恢复。这比事后凭记忆猜哈希靠谱太多。
6. 从搭建到免密：Git环境准备清单
6.1 各平台安装Git，别在第一步就卡住
虽然“代码提交还原”的命令本身不挑环境，但很多新手真正被卡住的反而是安装和配置环节，这里把主流平台过一遍。
Windows推荐直接使用Git for Windows，老牌安装包，自带Git Bash终端和Git GUI。装的时候有几个选项容易踩坑：
- 默认编辑器建议选VS Code或Vim，不要选Notepad；
- “Adjusting your PATH environment”保持默认的“Git from the command line and also from 3rd-party software”；
- “Checkout Windows-style, commit Unix-style line endings”默认即可，这个是针对换行符的。
macOS用户在终端里执行：
bash复制brew install git
没有Homebrew的话，直接安装Xcode Command Line Tools也会附带Git。Linux各发行版大同小异：
bash复制# Debian/Ubuntu
sudo apt install git -y
# CentOS/RHEL
sudo yum install git -y
安装完成后统一验证：
bash复制git --version
输出类似 git version 2.40.0 就说明环境没问题。
6.2 第一次使用前必配的两个参数
很多新手遇到“提交后代码作者信息不正确”的怪问题，十有八九是没配全局用户名和邮箱。这两项是Git提交信息里的必填字段：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
邮箱建议和代码托管平台（GitHub、GitLab、Gitee等）绑定的邮箱保持一致，否则提交记录没法正确关联到账号。 还可顺手设置新仓库默认分支名：
bash复制git config --global init.defaultBranch main
换行符的问题也值得在全局层面确认一下。Windows上默认设置 core.autocrlf=true 会在checkout时把LF转成CRLF，commit时再转回LF；macOS/Linux通常设 input 或保持默认。如果团队跨平台协作，最好的方案是提交一个 .gitattributes 文件统一规则，而不是各自改全局配置。
6.3 SSH免密配置，告别每次push输密码
热搜词里的“git免密”算是高频需求。这里说两种方案，推荐SSH。
生成密钥：
bash复制ssh-keygen -t ed25519 -C "you@example.com"
一路回车即可，默认路径是 ~/.ssh/id_ed25519。然后把公钥内容复制到托管平台的SSH Keys设置里：
bash复制cat ~/.ssh/id_ed25519.pub
添加完成后测试连通性：
bash复制ssh -T git@github.com
看到欢迎信息就表示成功了。之后 clone 远程仓库时选SSH地址，push就再也不用输入账号密码。
如果出于某些原因必须用HTTPS，可以配置凭据助手：
bash复制git config --global credential.helper store # 明文存储，不推荐
git config --global credential.helper cache # 缓存一段时间
Windows上如果安装了Git Credential Manager，首次push会弹窗验证，之后自动记住；macOS默认使用osxkeychain。要注意 store 模式会明文保存凭据到 ~/.git-credentials，安全性很低，公司电脑上不建议这么干。 免密配好之后，Git操作摩擦会大幅下降。我见过太多人因为每次push要输密码，养成“攒了一大堆提交才推一次”的坏习惯，结果一旦需要还原或rebase，操作复杂度成倍上升。环境顺滑了，很多还原类操作才能真正轻松起来。
最后分享我自己的一个习惯：在本地随便建一个临时仓库，把这类还原命令挨个试一遍，尤其是 reset 的三档模式和 revert 的区别。纸上谈兵看一百遍，不如亲手造几次事故又救回来，之后在真实项目里遇到“git 代码提交还原”，你才不会慌。