只有三分钟的赛雷说句实话，我见过太多人因为一次 Git 误操作，五分钟之内从“今天手感不错”变成“完了，代码保不住了”。删错分支、reset 顺手按成 --hard、提交完发现密码躺在代码里、合并完才发现合并错了人……这些场景我自己全踩过，而且我可以很负责任地告诉你：每一次都有救。Git 真正值得感谢的地方，在于它把你每一次操作的后悔药都默默留在了仓库里，问题只是你有没有学会去拿。
这篇指南不是 Git 入门教程，也不是让你背命令大全，而是我这些年用 Git 救火的经验整理出来的急救手册。不管你是命令行党，还是用 VSCode Git 插件、小乌龟（TortoiseGit），底层机制完全一样，我会尽量给命令行版本，因为它是所有图形工具背后的“通用语言”。如果你曾因为一次误操作丢掉代码、被迫加班到深夜，这篇应该能帮你省下好几个通宵。
1. Git 的后悔药仓库在哪：reflog 与对象库
1.1 先理解 Git 为什么“丢不掉”数据
Git 的核心本质是一个内容寻址的文件系统。每次你用 git commit、git branch、git merge、git checkout，都会在 .git 对象库里生成一堆不可变对象——commit 对象、tree 对象、blob 对象。“不可变”的意思是，对象一旦写进库里，就不会被主动修改，只会被 git gc（垃圾回收）在特定条件下清理。所以，绝大多数情况下你丢的不是代码，而是指向代码的“引用”——也就是分支名、HEAD 指针——对象本体还稳稳地躺在对象库里。
这就像图书馆里那本书还在书架上，只是索引卡片被人抽走了。找回它，只需要重新生成一张索引卡片就行。理解这一点，是建立“Git 误操作不用慌”信心的第一步。
1.2 reflog：你的个人操作日志
reflog 的全称是 reference log，即“引用日志”。Git 会忠实记录 HEAD 和每个分支引用每一次变动：什么时候从哪个提交切到哪个提交，reset 之前指向哪里，merge 之前在哪里，checkout 之前又在哪。你只需要在终端跑一句：
bash复制git reflog
就能看到一串类似这样的历史：
code复制1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
2b3c4d5 HEAD@{1}: commit: 完成登录功能
3c4d5e6 HEAD@{2}: commit: 修改样式
4d5e6f7 HEAD@{3}: branch: Created from main
HEAD@{0} 是当前状态，HEAD@{1} 是上一步，依此类推。更狠的是，git reflog 不只记录 commit，reset、checkout、merge、rebase 都会留痕。这就是找回丢失提交的第一入口。
有人会问：reflog 能保留多久？默认情况下，reflog 里的记录在 90 天内不会被 gc 清理。这意味着你至少有三个月的时间去发现并修复误操作。当然，前提是那台机器还在、仓库还在。
1.3 fsck：从对象库底层翻出“孤儿提交”
有些场景 reflog 里查不到记录，比如 CI 脚本、某些 GUI 操作或者手动清理过 reflog。这时候还有一招：直接扫描对象库里的“悬空对象”：
bash复制git fsck --lost-found
# 或
git fsck --dangling
它会找出所有“没有被任何引用指向、但依然存在”的提交。这些就是名副其实的孤儿提交，但通常正是你丢失的内容。我见过一个小伙子误删分支后又随手跑了 git gc，reflog 已经空的，我用 git fsck --lost-found 硬是从对象库里翻出了那两个提交，而且文件内容毫发无损。
提示：
git fsck算最后的底牌，能走到这一步说明常规手段已经失效。它对你的 Git 版本有一定要求，但绝大多数现代 Git 都支持。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 删错分支、硬重置之后：30 秒找回丢失提交
2.1 误删分支的急救流程
先说一个我自己的真实事故。有次我在一个项目里做了两天的新功能，全在 feature/login 分支上，还没推远端。整理分支时头脑一热，执行了：
bash复制git branch -D feature/login
一瞬间，命令行干干净净，我在原地愣了三秒。当时的感觉就是“完了，两天白干”。但冷静下来，我想起了 reflog。分支被删掉，不代表提交被销毁——分支名字没了，但 HEAD 的 reflog 里还留着这串提交的 hash。
正确的急救操作是这样：
bash复制# 第一步：查看 reflog，找到删除之前 HEAD 所在的位置
git reflog
# 第二步：直接基于那个提交重建分支
git branch feature/login <commit-hash>
就这么两条命令，熟练之后真的 30 秒内完成。注意，<commit-hash> 填 reflog 里你最后看到的那个“feature/login 分支开发中”的提交。重建分支后，你可以立刻 git log 确认内容是否完整。
2.2 误 reset --hard 的急救流程
另一种高频事故是 git reset --hard。比如你想撤销最近 5 个提交，脑子一抽，执行了：
bash复制git reset --hard HEAD~5
执行完才发现，那 5 个提交里有新功能的完整实现，还没推远端，说没就没了。这时候依然靠 reflog：
bash复制git reflog
# 输出里会有一行类似：
# abc1234 HEAD@{1}: reset: moving to HEAD~5
# 这一行之前的那个提交，就是 reset 前的位置
# 直接硬重置回去
git reset --hard abc1234
这里有个细节值得注意：reset 前那个提交 hash，其实就是你当时 HEAD 指向的提交。reflog 里 reset: moving to HEAD~5 这一行的上一行，往往就是 reset 之前的状态。找回后建议不要立刻做新的提交，先 git log 确认内容，再继续开发。
2.3 误操作后的“黄金 30 秒”定力
我要特别强调一点：误操作后最怕的不是丢代码，而是手忙脚乱又执行了一堆新命令。 这会把 reflog 挤到更靠前的位置，增加排查难度。我的个人习惯是：误操作后第一时间 git reflog 看一眼，不管看不看得懂，把它截图存下来，然后停下来思考。千万不要连着敲 git reset --hard、git checkout -- . 这种破坏性命令。
另外，如果误删除分支前你曾经把这个分支推送过远端，还有一条更省事的路径：直接 git clone 远程仓库或用 git branch -r 查看远程分支，从远端拉回来。所以养成“重要分支及时推送”的习惯，远比你学一百个急救技巧都管用。
2.4 找回后别忘了“加保险”
用 reflog 找回提交后，我一般不会直接 git reset --hard 回到原位置，而是先新建一个备份分支指向找回的提交：
bash复制git branch backup/recovered <commit-hash>
确认内容无误后，再把当前分支重置过去。这样就算后续操作又出问题，备份分支还在，等于给“后悔药”又上了一层保险。
3. 提交撤销三兄弟：amend、reset 与 revert 到底怎么选
3.1 三兄弟的药理区别
提交完成之后想反悔，Git 给了你三个工具：git commit --amend、git reset、git revert。很多人记不住这三个命令的区别，一遇到“撤销提交”就随便选一个。实际上三者的适应场景差异很大：
| 命令 | 原理 | 是否改写历史 | 适用场景 |
|---|---|---|---|
git commit --amend |
合并进最近一次提交 | 是 | 修改最后一次提交信息、漏提交文件 |
git reset --soft/mixed/hard |
移动分支指针到过去某个提交 | 是 | 本地提交想彻底抹掉或重新整理 |
git revert <commit> |
生成反向新提交抵消旧提交 | 否 | 已推送远端，需要保留历史 |
一句话总结：本地没推送，随便 reset；已经推送且别人可能拉过，用 revert；只想改最后一次提交，用 amend。
3.2 提交信息写错：amend 救场
这个场景几乎人人都遇到过：
bash复制git commit -m "fix typo"
# 然后发现信息写错了
git commit --amend -m "fix login bug"
amend 还有一个妙用：漏提交文件时，可以先 git add 漏掉的文件，再执行 git commit --amend，就会把新内容并入上一次提交，而不是新增一个提交。这在团队协作里非常有用，能让你的提交历史保持干净。
但要注意：amend 会生成一个新的 commit hash。如果原来的提交已经推送到远端，那么本地和远端的历史就对不上了，需要 git push --force-with-lease 才能同步。在公共分支上，这可能会影响到其他人。
3.3 reset 三模式：为什么 --hard 最需要警惕
git reset 有软、混合、硬三种模式，很多人只记住了 --hard，这是最容易出事的点。
| 模式 | 分支指针 | 暂存区 | 工作区 | 适用场景 |
|---|---|---|---|---|
--soft |
回退 | 保留 | 保留 | 想重新整理提交，把上次提交整体收回暂存区 |
--mixed（默认） |
回退 | 清空 | 保留 | 想保留改动但取消暂存 |
--hard |
回退 | 清空 | 清空 | 想彻底丢弃改动 |
场景举例：刚提交完，发现提交把不该提交的文件也带进去了，想重新组织：
bash复制git reset --soft HEAD~1
# 这时候改动全部回到暂存区，你可以 git reset 再 git add 指定文件
如果你只是想取消暂存，而不是彻底不要改动，用 git reset（默认 mixed）就够了。只有当你非常确定“这些改动真的不要了”，才用 --hard。
3.4 revert：已推送提交的安全撤销
提交已经推送到远端，而且同事可能已经拉取了，这时候不要用 reset 改写历史，否则同事下轮 pull 会撞上一堆冲突，严重时还会互相覆盖。
正确做法是 git revert：
bash复制git revert abc1234
它会生成一个新提交，把 abc1234 的修改反向应用一遍。历史是往前走的，其他同事正常 git pull 就能得到你的撤销效果，不会有任何历史冲突。revert 还支持批量处理多个提交：
bash复制git revert --no-commit A B C
# 把 A、B、C 三个提交的反向修改全部合到一个新提交里
git commit -m "revert A B C"
3.5 revert 遇到冲突也别慌
别指望 revert 永远是“一键撤销”。本质是反向 merge，一样会有冲突。我曾经 revert 一个改动面横跨十几天的老提交，结果几十个文件的冲突。这时候只能手动解决，一步步 git add、git commit，和普通 merge 冲突的处理流程一模一样。所以 revert 不是不能做，而是要选对时机：越早 revert，冲突越少。
3.6 误提交敏感信息的紧急处理
这是 Git 救火车站里最刺激的一种：把密码、token、API key 提交进了历史，还推送到 GitHub 了。我给你的第一反应不重要，第二反应很重要：
第一步，立刻去平台或服务商吊销、重置这个凭证，不是先删代码。凭证只要泄露过，就算删了历史也可能已经被别人爬走了，所以先作废。
第二步，清理仓库历史。如果只在最后一次提交里，用 amend 就能处理；如果已经在历史里躺了好几个提交，最干净的手段是 git filter-repo：
bash复制git filter-repo --path config/secrets.yml --invert-paths
这是 GitHub 官方现在推荐的替代 filter-branch 的工具。跑完后历史彻底改写，再 --force-with-lease 推远端。注意，所有协作者需要重新 clone 仓库，因为本地旧历史和新历史对不上。这个场景 30 秒救不了全程，但思路一样：数据还在，就能处理。
4. 开发开错分支、合并合错人：分支手术与 merge 撤销
4.1 代码全部做在了错误分支上
团队里总有人习惯直接 checkout main 开写，等要提 PR 才发现所有改动都堆在了 main 上。这种场景处理起来其实非常快：
bash复制# 第一步：基于当前 main 上的内容创建新分支
git checkout -b feature/xxx
# 第二步：推送到远端
git push origin feature/xxx
# 第三步：将本地 main 重置到远端 main 的状态
git checkout main
git reset --hard origin/main
这样功能代码就被“搬”到了新分支上，main 也恢复干净。这里最危险的是最后一步 reset --hard origin/main，操作前务必确认 main 上没有其他你没推送的新提交。稳妥起见，先 git log --oneline origin/main..main 看看本地 main 比远端多出哪些提交，确认都是你要“搬走”的再执行。
4.2 只想带走其中一部分提交：cherry-pick
如果错误分支上的提交并不是全都想要，可以用 cherry-pick 精准挑选：
bash复制git checkout feature/target
git cherry-pick <commit-hash>
它会把这个提交的改动应用到当前分支。多个提交可以按顺序逐一 cherry-pick，也可以用范围一次搞定：
bash复制git cherry-pick A^..B
注意范围是从 A 到 B，A^ 表示 A 的父提交，用来包含 A 本身。这个命令太好用了，团队协作中经常能用来把某个紧急修复从一个分支“复制”到另一个分支，而不用等合并整个历史。
4.3 误 merge 后的三级撤销方案
合并这种事，谁都可能搞错。针对不同阶段，撤销方案不一样：
第一级：合并过程中发现冲突，不想合了
bash复制git merge --abort
这会在合并还没完成时恢复到你 merge 之前的状态，所有合并相关的临时内容都会清理掉。这是最温和、最安全的撤销。
第二级：合并已经完成，但还没推远端
bash复制git reset --hard HEAD~1
# 或者用 merge 前那个提交的 hash
git reset --hard <merge前commit>
因为 merge 提交本质上是一个“新提交”，reset 回父提交就相当于把 merge 整个抹掉。
第三级：合并已经推送到远端
bash复制git revert -m 1 <merge-commit-hash>
这里 -m 1 的意思是保留第一父分支（也就是合并前的主线），把第二父分支（被合并进来的分支）的改动整体撤销。很多人第一次见 -m 参数会懵，记住它的用途就行：指定 revert 合并提交时保留哪条线。
4.4 force push 的安全带：--force-with-lease
只要涉及改写历史，最后总要强推。但裸用 git push --force 非常危险，它不检查远端状态，直接覆盖。Git 新版本提供了安全带：
bash复制git push --force-with-lease
它的工作机制是：推送前对比本地记录的远端引用和远端实际状态，如果发现远端在你最后一次 fetch 之后又有新提交，就主动拒绝推送，避免覆盖别人刚推上去的代码。我们团队有硬性约定：改写公共历史必须用 --force-with-lease，并且提前在群里通知全组。 这个习惯救了项目不止一次。
5. 工作区被清空、文件被覆盖：找回未提交内容
5.1 git checkout -- . 误用后怎么办
这是最让人头皮发麻的操作之一：看着工作区乱糟糟，想放弃所有修改，执行了：
bash复制git checkout -- .
然后发现把几个还没写好的新功能也一起“还原”到上次提交的状态了。这里我必须先泼一盆冷水：如果这些文件是被 Git 跟踪过的，checkout -- . 会把工作区直接恢复成上次提交的样子，用户原始的修改会被覆盖掉。Git 本身不太能找回这些内容。
但别绝望，现实里有几个补救方向：
- 编辑器本地历史：VSCode 里右键文件，选择 “Local History” 或打开时间线面板，能看到文件历次被编辑保存的版本快照。
- 备份插件：JetBrains 系的 Local History、VSCode 的本地历史扩展，都能在关键时刻捞一把。
- 如果改动曾进入过暂存区：
git reflog和git fsck有可能找到对应对象，但概率较低。
所以最可靠的防护不是等出事再救，而是养成习惯：在 checkout、reset --hard、git clean 这类破坏性操作前，先 git stash push -u 或直接复制一份工作区备份。多花十秒钟，省下一整夜。
5.2 git clean -fd 删掉未跟踪文件的恢复思路
git clean 的作用是删除未跟踪文件和目录，很多人不了解参数含义就直接抄命令，比如：
bash复制git clean -fd
-f 是 force，-d 是包含目录。一旦执行，所有未跟踪文件（包括 .env.local、临时脚本、没纳入 Git 的配置文件）直接消失，而且不会进回收站。更糟的是，如果这些文件从来没被 git add 过，Git 的对象库里自然没有对应的对象，git fsck 也翻不出来。
唯一可能救回的场景：文件曾经被 git add 过但没提交。这时候对象库里可能有 blob 对象，可以试试 git fsck --lost-found 在 .git/lost-found/other 目录里找找看。如果从未 add 过，只能寄望 IDE 本地历史或你手动备份。
5.3 还没提交却被覆盖：stash 是最后的保险箱
有时候你改了文件 A，突然要切分支，Git 提示 Would be overwritten，有些人图省事直接 git checkout -- . 或 git reset --hard 继续操作，改动就没了。其实这个提示是 Git 在救你，这时候正确姿势是：
bash复制# 临时存起来（-u 表示连未跟踪文件一起存）
git stash push -u -m "暂存未提交改动"
# 切换分支、处理完毕后再恢复
git stash pop
stash 就像临时保险箱，可以把你当前所有未提交的改动打包存起来，清空工作区，之后随时再拿出来。git stash list 查看所有 stash，git stash apply 可以在不删除记录的情况下恢复，git stash drop 删除指定记录。我在大改代码、重构、切 hotfix 分支前都会 stash 一次，这个习惯帮我避免过无数次“改了半天切个分支全没了”的悲剧。
5.4 git restore：更现代的恢复命令
很多新版本 Git 提供了 git restore，它是比 checkout 更语义化的恢复命令：
bash复制# 恢复工作区文件到最近一次提交
git restore <file>
# 取消暂存（相当于 old: git reset HEAD <file>）
git restore --staged <file>
git restore 上手简单，语义清晰，尤其适合只想“撤销某个文件”的场景，不会像 checkout 那样容易误伤整个分支状态。如果你发现自己经常搞混 checkout 的两种用途（切分支 vs 恢复文件），建议直接切换到 restore。
6. 急救速查表与让事故变少的日常习惯
6.1 速查表：贴在工位上，出事直接看
| 事故场景 | 急救命令 |
|---|---|
| 误删本地分支 | git reflog 找到 commit，git branch <name> <hash> 重建 |
误 reset --hard |
git reflog 找到旧位置，git reset --hard <hash> |
| 提交信息写错，未推送 | git commit --amend -m "新信息" |
| 提交已推送，想撤销 | git revert <commit-hash> |
| 提交到了错误分支 | git checkout -b 正确分支 + git reset --hard origin/原分支 |
| 只想搬运某次提交 | git cherry-pick <commit-hash> |
| 误 merge 未推送 | git reset --hard HEAD~1 |
| 误 merge 已推送 | git revert -m 1 <merge-hash> |
| 合并冲突时想放弃 | git merge --abort |
| 工作区被覆盖 | 编辑器本地历史 / stash / 备份 |
| 误 clean 删文件 | 未跟踪文件基本无法恢复，先看 IDE 历史 |
| 误提交敏感信息 | 先改凭证，再 git filter-repo 清理历史 |
6.2 让误操作概率降下来的日常习惯
作为 Git 的日常使用者，我想说：急救很重要，但真正成熟的开发者靠的是让事故少发生。这几点是我从踩坑里总结出来的：
- 提交规范先行：采用 Conventional Commits 之类的统一格式，一条提交只做一件事。这样每次 revert、cherry-pick 都是精准操作，不会误伤其他功能。
- 重大操作前看状态：执行
git reset --hard、git checkout -- .、git clean -fd之前，先git status，再git log --oneline -5，确认自己在哪、要退到哪。 - 重要分支及时推送：本地分支不推远端，丢了就是真丢了；推了远端，至少还有第二个副本。很多人丢失代码的根本原因不是误操作，而是零备份。
- 开启分支保护：在 GitHub/GitLab 上给 main/master 配置保护规则，禁止直接 push，强制走 PR。
- 统一换行与文件权限配置：
core.autocrlf、core.filemode不一致会导致莫名其妙的 diff，团队最好统一。 - 提交规范里留下线索：revert、rebase 后建议在提交说明里写清楚理由，方便以后的人考古。
6.3 遇到 Git 报错的三步排查法
如果上面的急救都不对症，你遇到的可能不是误操作，而是环境或配置问题。比如两个高频报错：
git 不是内部或外部命令：这是 Windows 环境变量 PATH 没配置好，重新安装 Git 时勾选 “Add to PATH”，或者直接使用 Git Bash 就解决了。fatal: not a git repository：说明你当前目录不是 Git 仓库（没有.git目录），先确认cd是不是进错了目录。
我的通用排查流程是：第一步 git status 和 git log --oneline -5 看清当前状态；第二步 git reflog 看最近发生了什么；第三步把报错原文完整复制到搜索框里查，不要自己瞎猜命令。90% 的 Git 疑难杂症都能用这三步解决。
最后再分享一个小体会：Git 最反直觉但也最迷人的地方，是它默认不会主动销毁你的数据，几乎所有“丢失”都只是“找不回来”。只要你理解 reflog 和对象库这两个底牌，再配合 --force-with-lease 这类安全带习惯，你的代码其实比你想象中安全得多。真正需要修的，从来不是 Git，而是我们慌起来乱敲命令的手。希望这份急救指南，能帮你在下一次手滑之后，稳稳地把代码救回来。