1. 急救思路：先搞清楚还能不能救
Git 误操作，现实中多半不是“不会用”，而是“太顺手”。平时提交、切分支、拉代码都是肌肉记忆，一忙起来脑子还没跟上手指，手一滑就是事故。我在团队里见过太多这样的场面：有人把整个合并操作搞反，把别人的分支合进来又推了上去；有人 reset --hard 之后发现本地改了一个下午的代码消失干净；更常见的是提交信息写成“asdf”然后已经 push 到远端。每一个场景单看都算不上什么高级操作，但撞在一起就是致命的信任危机。
我的经验是，遇到 Git 事故先别急着乱操作，第一步永远是想清楚一个问题：我到底要救什么。是救“已经提交但位置不对的提交记录”，是救“被 reset 掉的工作区代码”，还是救“被误删的分支引用”。不同目标对应的恢复手段完全不一样，搞错了方向反而会把可救的局面搅成死局。
1.1 急救的三种类型：本地提交、工作区、远端引用
把 Git 误操作拆开看，绝大多数事故都逃不出三个层面。
第一类是提交记录层面的问题，比如提交信息写错、提交到了错误的分支、需要把多个提交合并成一个，或者想把某个已经提交的改动整体撤回。这类操作的核心参数是“提交的哈希值”，恢复或者修改的手段集中在 commit 和 reset 系列命令上。
第二类是工作区层面的问题，典型的是误执行了 reset --hard 或者 checkout -f，把尚未提交的修改给覆盖掉。这类事故往往最让人绝望，因为改动从来没有进入版本历史，给人的第一感觉就是“完了，代码没了”。但实际上 Git 的机制远比我们以为的宽容，后面会详细讲。
第三类是远端引用层面的问题，比如误推了一个不想推的分支、把别人的分支覆盖了、或者 push --force 之后远端历史被改写。这类事故比前两类复杂，因为它牵扯到其他人的本地仓库状态，不光要修自己的，还得考虑怎么让团队伙伴的操作不被影响。
把事故先归类，再对症下药，是我写这个“急救手册”的第一个原则。没有这一层归类，网上搜来的命令就是一堆没有上下文的咒语，越抄越乱。
1.2 Git 底层的救命机制：为什么大多数事故都能救回来
很多人不知道，Git 能“救回来”不是靠运气，而是因为它的存储机制天生就保留了大量现场痕迹。
Git 本质上是一个内容寻址的“键值对数据库”，每个提交对象、每个文件对象都有自己的哈希值。在 Git 的仓库里，只要一个对象被写入，它不会因为分支被删或者提交被 reset 就立刻消失，而是变成了“悬空对象”（dangling object），等待垃圾回收机制来清理。垃圾回收不会频繁自动运行，很多时候一次误操作之后，相关对象在仓库里还会存活很久，这就是我们能做急救的根本原因。
另一个关键的机制是 reflog。reflog 是 Git 用来记录“引用变更历史”的日志，简单说，它保存了你每一次 HEAD 移动、分支切换、reset、checkout 的记录，哪怕这个操作本身是“错误”的，reflog 里面也留着当时的哈希值。这意味着你完全可以通过 reflog 找到误操作发生之前的分支状态，然后精准跳回去。
打个生活化的比方：Git 的提交历史像是文章的最终稿，你 reset 掉一个提交，相当于把最终稿撕了。但 reflog 就像草稿纸旁边的回收站，每一版写过的内容都还在里面，只要名字没被覆盖，就能翻出来。理解了这两条底层机制，后面的所有急救步骤都有了依据，用起来心里也踏实。
2. 高频误操作场景解析与恢复原理
写急救手册，不能只列命令，得把每个命令背后的原理讲透。否则换个场景，你还是不会用。下面这几个是我在实践中遇到频率最高的误操作类型，每条都附上适用条件和边界。
2.1 提交信息写错或者提交内容不对：commit --amend 与 reset 怎么选
提交完之后发现信息写错了，或者发现少加了一个文件，最直接的手段是 commit --amend。它的本质是“修改当前分支最近一次提交”，并不会新增一个提交记录，而是把原提交替换掉。如果你的错误提交还没有推送到远端，这个操作几乎零成本，改完直接 push 就行。
但有一个前提需要特别注意：commit --amend 会改写提交的哈希值。如果这个提交已经推到了远端，而且还有其他同事基于这个提交做了新提交，那你就不能用 amend 去改它，否则会造成远端历史分叉，同事拉取代码时会遇到莫名其妙的冲突。这种情况下，正确做法是新增一个提交来“修正”，也就是 git revert。
还有一种情况，是你把文件提交错了分支。比如你人在 main 分支上，结果把属于 feature 分支的开发改动提交到了 main。这时候不要用 revert，因为 revert 是生成一个反向提交把改动取消掉，但从后面追加一个“撤销提交”会污染 main 的历史。更合理的做法是：先用 git reset --soft HEAD~1 把这次提交撤销，但保留工作区和暂存区的内容，然后切到正确的分支重新提交。
git reset 的三种模式正好对应不同的需求：--soft 只动提交记录，不动暂存区和工作区；--mixed（默认）会把提交撤销，同时把暂存区内容退回工作区；--hard 则是连工作区内容一起清掉。急救场景下，我强烈建议优先用 --soft 和 --mixed，因为这两个模式都不会真正弄丢你的代码，最坏结果无非是改动回到工作区让你重新整理。
2.2 手滑 reset --hard 之后，怎么把“消失”的提交找回来
reset --hard 是 Git 里最危险的命令，没有之一。因为它会把工作区、暂存区、当前分支引用全部重置到目标位置，所有未提交的修改会直接消失。很多新人第一次遇到 reset --hard 事故，第一反应是关掉终端假装没发生，或者疯狂翻 IDE 的 Local History，但 IDE 的本地历史通常只保留编辑器打开过的文件，覆盖面远不如 Git 自己的机制广。
正确的找回路径是这样的：reset --hard 之后，分支引用的指针变了，但原来的提交对象并不会立刻从仓库里删除。你只需要去 reflog 里找到那个提交的哈希值，然后把分支重新指过去就可以了。
具体操作分两步。先执行 git reflog，在输出列表里找到 reset 操作前的那一条记录，通常能看到类似“HEAD@{1}: reset: moving to xxx”这样的行，这行的前面会有一个 commit 哈希。然后执行 git reset --hard <这个哈希>，分支就回到误操作之前的状态了。
但这里有个常见的困惑：reflog 里有很多条记录，到底选哪一条？我的办法是，在误操作之后不要让仓库发生新的 reset、rebase、checkout 操作，因为每执行一次，reflog 头部就会新增一条记录，原本那条会往下沉。如果你已经做了一堆别的操作，可以在 reflog 里按时间和描述判断，reset 之前的描述通常是“commit: xxx”，而不是“reset: moving to xxx”，认准这条基本不会出错。
2.3 合并操作搞反了：revert 与 reset 在合并场景下的区别
合并代码时出错，是团队协作中最容易踩的坑。比如你想把 feature 分支合并进 main，结果 git checkout feature 之后直接 git merge main，等于把 main 的最新代码合进了 feature。更麻烦的是，如果这个合并操作已经 push 到了远端，你就没法用 reset 简单回滚，因为这会破坏远端其他同事的本地历史。
处理已推送到远端的错误合并，核心命令是 git revert -m 1 <merge_commit_hash>。-m 参数指定要保留哪条父分支，1 表示合并提交的第一父提交，也就是你当前所在的分支。执行之后 Git 会生成一个反向提交，把合并带来的改动全部撤销，但历史记录上保留了这次合并和撤销的完整痕迹。
这里很多人会问：为什么不能直接 reset 到合并之前？我的观点是，如果是本地操作，还没 push，那 reset 到合并前确实更干净，历史看起来就像没发生过合并一样。但一旦 push 了，团队的其他人可能已经基于这个合并提交做了新的开发，你 reset 之后 force push，会直接导致同事的本地仓库历史错位，轻则 pull 冲突，重则丢失提交。所以，已推远端的场景，只要不是灾难性的，就老老实实用 revert 保平安。
3. 实操步骤：典型误操作的完整恢复流程
原理讲再多，不实操还是会手忙脚乱。这一节我按照事故类型，给出可以直接“抄作业”的恢复步骤，每一步都尽量写清楚操作意图和判断依据。
3.1 撤销本地错误提交，但保留代码改动
适用场景：你刚在本地提交了一版代码，马上发现提交信息写错，或者提交内容不完整。
第一步，查看当前提交状态。执行 git log --oneline，确认最近的提交哈希和描述，防止后面操作选错对象。
第二步，判断这个提交是否已推送远端。执行 git log origin/<当前分支>..HEAD，如果这行命令输出内容为空白，说明本地提交没有包含任何远端没有的提交，还没有推送。那你可以放心用 git reset --soft HEAD~1，撤销最近一次提交，暂存区和工作区的内容都会保留。
第三步，重新整理提交。如果只是提交信息问题，执行 git commit --amend 修改信息；如果是漏了文件，先 git add 补充文件，再执行 git commit --amend 合并进同一个提交。
如果这个提交已经推送到了远端，就不能用 reset 了。正确流程是执行 git revert HEAD，Git 会打开一个编辑器让你填写新提交信息，默认内容是“Revert '你的原提交信息'”。保存后会让远端追加一个反向提交，效果等同于撤销，但历史是线性增长的，不会影响其他人。
3.2 恢复误删的分支：reflog 大显身手
适用场景：你执行了 git branch -D 删除一个分支，或者用 git checkout 加 git branch -d 的连锁操作，之后发现分支上的提交全没了。
第一步，先稳定情绪，别做任何新操作。第二步，运行 git reflog --all，注意这里加了 --all，它的输出会包含所有分支的引用变更，比普通的 git reflog 覆盖范围更广。
在 reflog 列表里，找到被删分支最后一次提交记录。假设你要找的分支叫 feature/logic，reflog 里通常会有一行类似于“<哈希值> branch: Created from main”或者“<哈希值> checkout: moving from feature/logic to main”的记录。这行的哈希值就是分支最后一次指向的提交。
第三步，执行 git branch feature/logic <哈希值>，重新创建分支并指向那个提交。这一步完成后，被删分支的整个提交历史就回来了，直接 checkout 过去即可继续开发。
这里需要提醒：如果删除分支之后你有过大量提交、reset、merge 操作，reflog 记录可能被覆盖，旧记录下沉后仍然存在，但排序靠后。不要因为在前面找不到就放弃，往下多翻几页，Git 的 reflog 默认会保留 90 天，时间窗口足够宽。
3.3 stash 误操作：把藏起来的改动弄丢了怎么办
stash 本身的误操作主要有两类：一类是 git stash drop 误删了某个暂存记录，另一类是 git stash pop 应用之后发现和工作区冲突一堆，想退回但 stash 列表里的记录已经被清掉了。
先说第一类。git stash drop 之后， stash 对象会变成悬空状态。可以用 git fsck --no-reflogs 来排查悬空提交对象。执行 git fsck --unreachable 2>/dev/null | grep commit，输出结果里会列出未被引用的提交对象。这些对象里面有可能是 stash 产生的。找到之后执行 git stash apply <对应对象哈希>，就能把改动恢复到工作区。
当然这样一个个排查哈希有点头疼。更实用的做法是用 git log --all --grep="WIP on" 或者直接查看所有 stash 相关对象，因为 stash 的提交信息默认带有“WIP on 分支名：日期”的特征，比较容易辨别。
第二类，pop 之后出现冲突。解决冲突通常会花很多时间，如果你中途想放弃，想回到 pop 之前的状态，可以用 git checkout -f 或者 git reset --hard 恢复工作区，但注意 stash 记录已经被 pop 清掉了，得先让 stash 记录恢复才能在另一个时间点重新应用。恢复 stash 记录的办法还是靠 fsck 找悬空提交。
我的建议是，凡是涉及到 stash 的操作，尤其是 pop 和 drop，执行之前都养成习惯检查一下 git stash list。如果看到 stash 记录里只有一个且是你刚创建的，那 drop 或者 pop 前的确认就要格外谨慎。
3.4 误 merge 到本地后想撤销：两种思路的取舍
场景：你在 main 分支上执行了 git merge feature/login，合并完成后发现 feature/login 的代码还远未达到上线标准，想把这次合并撤销。
如果合并还没推送远端，直接用 git reset --hard HEAD~1 即可，合并提交会消失，分支回到合并之前的提交。这个操作不会丢失 feature/login 分支本身，因为那个分支的提交记录还是完整的，只是 main 分支不再包含这些改动。
如果合并已经推送到了远端，就执行 git revert -m 1 HEAD。-m 1 表示保留主分支的历史，生成一个反向提交来抵消合并提交的全部改动。注意 revert 之后，后续想重新合并 feature/login 进来时，会碰到一种特殊情况：因为之前的合并已经被 revert 了，Git 会认为“这个分支已经合入过 main”，直接 merge 会提示 Already up to date。这时候需要 git revert <那个 revert 提交的哈希>，先把撤销合并的操作也撤销掉，再重新合并。这个嵌套操作的顺序容易乱，建议在团队文档里明确记录每个 revert 的上下文，不然一个月后连自己都看不懂。
4. 进阶恢复操作：用 fsck 与 reflog 组合捞回失联的代码
前几节讲的场景都比较明确，但急救手册要应对的不只是“明确的事故”，还有那些说不清发生了什么、只知道代码没了的状况。这种时候，就需要动用 fsck 和 reflog 的组合拳，把仓库里的“失踪人口”一个个捞出来。
4.1 通过 fsck 找回悬空对象：终极方案
fsck 的全称是“filesystem check”，如果你的仓库文件结构出现问题，fsck 可以检查对象完整性。在急救场景里，我们主要用它来找悬空对象。这些对象通常包含被 reset、rebase、或者 stash drop 操作“遗弃”的提交数据。
最常用的救命命令是 git fsck --lost-found。执行之后，Git 会列出所有不可达的提交对象、树对象和文件对象。对于提交对象，你可以尝试用 git show <哈希> 查看内容，符合条件的就新建分支或者 cherry-pick 到当前分支。
为什么强调“终极方案”？因为这个命令的输出信息非常原始，没有分支名，没有提交信息提示，只看得到一串哈希。你需要靠自己的判断力去辨认每一个对象是不是你要找的东西。实操时我的经验是，先用 git show <哈希> --stat 查看这个提交影响了哪些文件，再决定是否救回来。这个验证步骤能大大减少误判概率。
另外，fsck 并不是所有情况都能搜遍全库。如果你用 git gc 手动执行了垃圾回收，悬空对象很可能被真的清掉了。所以，急救的第一原则依旧是：误操作之后，别急着执行 gc，别急着装任何“优化脚本”。
4.2 从远程仓库找回本地丢失的提交
有些情况下本地仓库的状态已经彻底乱了，但远端仓库还在，这是最幸运的局面。比如你误操作之后本地分支重置了，但之前某个提交已经 push 到远端，你可以直接在远端找到那个哈希。
执行 git fetch origin，把远端所有引用下载到本地。然后 git log origin/分支名 --oneline，检查远端分支上是否存在你要找的提交。找到了就直接执行 git cherry-pick <哈希> 或者 git reset --hard origin/分支名，把提交找回来。
如果远端也没有，那就只能看其他人有没有。比如误操作之前，同事可能 pull 过你的分支代码，在他本地是存在同样提交的。让他执行 git push origin HEAD:<你的分支名>，或者直接把他分支上的提交 cherry-pick 过来，也能实现恢复。这也是为什么我一直强调团队协作中，及时推送是一个“隐形的备份机制”。
4.3 恢复已覆盖的远端分支：force push 的补救流程
操作远端分支时，最常见的灾难是有人执行了 git push --force，把自己的历史覆盖了别人的提交。一旦发生，远端分支的提交记录会被改写，其他同事 pull 时会收到“非快速前进”的警告。
如果被覆盖的分支就是你的开发分支，而你有本地备份，那恢复思路是：在自己的本地仓库执行 git reflog，找到被覆盖之前的分支状态，新建一个临时分支指向那个状态，然后 push 上去。
如果本地也没有完整备份，但另一位同事拉取过旧版本，可以请他在本地执行 git reflog，同样找回之前的提交。恢复之后，原路 push --force 回去。这个操作本质上是“再覆盖一次”，但覆盖的结果是正确历史。
这里有个极其重要的注意事项：在执行 force push 恢复之前，必须和涉及此分支的所有同事同步，让大家都别在这段时间提交代码，否则会陷入双方互相覆盖的循环。我已经见过太多团队在互相覆盖之后反复 force push，最后只能靠 FSck 一个个捞对象的惨案，完全是可以用沟通避免的。
5. 常见问题与排查技巧实录
急救手册写到这一步，核心命令基本就齐了。但在实际运用中，你会发现光是“知道命令”并不够，还有一堆零碎问题需要处理。这里我把这些年遇到的高频困惑和排查技巧整理成一份速查表，方便遇到问题时直接对照。
5.1 恢复出来代码不对怎么办
git reflog 和 git fsck 给出的哈希，恢复之后不一定就是你想要的那个状态。很多时候，你以为是“最后一次提交”的那个哈希，其实可能是中间状态的合并点或者某次 checkout 产生的移动点。
我的排查习惯是：先不急着 reset 或 checkout，把候选哈希逐个用 git show 看一遍。重点看提交的提交信息、时间戳和改动文件列表，三样都能对上，再执行恢复操作。如果 git show 看了几个都不太对，多半是 reflog 里的记录已经因为后续操作被覆盖下沉了，你找到的其实是更早的记录。这时候可以把时间范围拉大，在 reflog 输出里查找误操作发生时间点前后的记录，别只看前面几条。
5.2 恢复提交后发现工作区一堆冲突
这在恢复 stash 或者 cherry-pick 时特别常见。原因很简单：你恢复的是历史某个时间点的状态，而当前工作区已经向前走了很多步，两边的改动在同一个文件里重叠了。
处理思路，先明确一点：冲突不等于失败。Git 把冲突的部分用 <<<<<<< 和 >>>>>>> 标记出来，你只需要逐个文件打开，手动保留正确内容，然后 git add 标记为已解决，最后 git commit 完成恢复。
如果冲突太复杂，手动解决代价太高，可以考虑另一种路线：把当前工作区所有改动先 stash，恢复完成并提交后再把 stash 弹回来。这样可以把“恢复历史”和“保留新改动”两件事拆开处理，避免互相干扰。在操作之前建议拍一个当前的完整快照：执行 git diff > /tmp/pre_recovery.patch，这样即使后续操作失败，也能靠补丁文件找回当前改动。
5.3 恢复时选错了提交，把分支改得更乱
这是急救操作里最尴尬的场面：本来想恢复丢失的提交，结果手抖 reset 到了一个更早的状态，导致工作区又丢了一波改动。
别慌，这也是一次标准的 reflog 操作就能解决的。执行 git reflog，找到你执行错误 reset 之前的那一条记录（描述为“reset: moving to xxx”），然后用 git reset --hard <该记录哈希>。一次错误恢复造成的损失，可以用同一条机制再次恢复。但如果反复出现这种情况，就不是命令问题了，而是操作习惯问题。
保险起见，在做任何急救恢复之前，先创建一个全量备份分支：git branch backup/紧急备份时间戳。这个动作只需要一条命令，但能保证你无论如何瞎操作，都有一个绝对安全的落点可以回去。
6. 避坑经验与长期习惯
急救手册再全，也不如平时养成好习惯来得重要。我从自己踩过的一堆坑里总结了几条最值得养成的操作习惯，分享给所有还在与 Git 搏斗的朋友。
6.1 高危命令执行前的“三层确认”
reset --hard、push --force、checkout -f，这三类命令我统称为“高危命令”。执行之前，我会强制自己做三件事：第一，先跑 git status，看清当前分支和未提交的改动；第二，先跑 git log --oneline -5，确认自己所在的位置；第三，心里默念一遍命令的完整含义，比如“git reset --hard HEAD~1 会把当前分支指向上一个提交，同时工作区所有未提交改动清空”，念得出的才准执行。
听起来很啰嗦，但实测下来能挡住九成的手滑。尤其是团队协作环境下，一个 force push 能波及的人太多了，花十秒钟做确认，比事后花一小时做急救划算得多。
6.2 推送节奏与分支保护
尽可能保持高频推送。很多误操作之所以变成灾难，是因为本地积累了大量提交结果一次性被 reset 掉。如果每次改动都及时 push，那么即使本地全丢，远端至少有一份接近最新的版本兜底。
同时，在团队仓库里建议开启分支保护规则，禁止普通成员对主干分支直接 push --force。合理的管理方式是：主干分支只接受 merge request 合入，个人开发分支可以自由操作，但远端历史改写必须通知到团队。这一条能在制度层面挡住一大半合作事故。
6.3 本地仓库的“定期备份意识”
很多人以为 Git 仓库不需要备份，其实这是个误解。本地 .git 文件夹里保存了 reflog、悬空对象这些救命数据，但如果你误删了整个 .git 目录，或者执行了 git gc --prune=now，那这些数据也会消失。
我现在的做法是，每周至少对核心仓库执行一次整库备份：git clone --mirror 仓库路径 /备份路径/仓库名.git。镜像克隆会把所有分支、标签、引用都带一份，即使本地仓库彻底损坏，也能凭这份镜像快速恢复。对一个长期维护的项目来说，这一条投入产出比极高。
6.4 急救流程文档化
最后一条经验：别把人脑当缓存。团队内一旦执行过一次 Git 急救，就把过程记录下来，包括当时发生了什么、用了什么命令、为什么这样用、最后结果如何。这些记录的价值远超你临时搜索到的任何博客文章。
我现在维护的团队 Git 排障文档已经积累了几十个案例，每次有新同事加入，我都会让他先读一遍。过去一年里团队因为 Git 误操作导致的“生产事故”基本清零，不是大家不再犯错了，而是每个错误都有人趟过了路，后来的人照着走就行。
急救手册的最终意义，不是让你成为专家，而是让你在慌乱的时候，有章可循。我自己最深的体会是：Git 误操作并不可怕，真正可怕的是误操作之后乱来一气，把小问题折腾成大灾难。你越了解 Git 的底层机制，越能保持冷静，剩下的就是照着流程一步步走完而已。
