1. 急诊第一课：先搞清楚"病人在哪"，再谈抢救
我见过太多人搞错顺序。在某个技术社区看到一条提问，标题写着"git reset --hard 后代码没了怎么办"，点进去一看，他还没跑git reflog就开始重写代码了。这就好比人进了急诊室，家属不问医生情况如何，先自己开始做心肺复苏——方向可能全反了。
Git误操作这件事，先说一个能让你立刻安心的事实：Git里绝大多数误操作，都不是真的删除，只是把指针挪走了。提交对象、树对象、内容对象都还躺在.git/objects里，只是没有任何引用指向它们，暂时变成了"悬空对象"。只要它们还没被git gc物理清理，理论上全部都能找回来。
所以这篇文章的真正重点，不是教你把Git命令背熟，而是帮你建立一套"急救分诊"的逻辑：误操作发生后，第一步不是回忆命令，而是判断"我现在在哪个状态"，然后找到对应的救援工具。
误操作分级： - 一级（轻度）：工作区文件被覆盖、暂存区内容被冲掉，但提交历史没变 - 二级（中度）：提交记录被改动（reset / amend / rebase），但还有reflog可查 - 三级（重度）：分支被删、悬空对象即将被清理、跨设备无法访问原仓库每一级有不同的救援手段和成功率。文章后面我会按这个逻辑展开。
2. 急救工具链：reflog、fsck、stash 是你的三张底牌
在讲具体救援方案之前，先把最核心的三个工具讲透。这三个命令覆盖了90%以上的救援场景，而且它们有一个共同特点：读取的是Git内部日志或底层对象库，不依赖你当前的代码状态。也就是说，哪怕当前工作区已经乱成一锅粥，这三张底牌依然可用。
2.1 git reflog：你的"时光倒流机"
git reflog是每次救援操作的第一选择。它记录的是 HEAD 指针在过去一段时间内的每一次移动——包括 commit、reset、merge、rebase、checkout 换个分支、cherry-pick，甚至是你执行了git commit --amend之后原来的提交被替换掉的那一瞬间。
# 查看所有分支的引用日志，不只是当前HEAD git reflog show --all # 带时间信息的reflog，方便定位到特定时间点 git reflog --date=iso # 只看某个分支的历史，比如你刚搞坏的dev分支 git reflog show dev--all参数我尤其建议在急救时加上。默认的git reflog只显示当前分支的移动记录，但很多时候你误操作的对象可能已经不是当前HEAD了——比如你做了一个git branch -D删了分支，当前HEAD是另一个分支，那默认reflog里根本看不到被删分支的移动记录。加上--all才能看到另一个分支最后的commit ID。
有一个概念要区分清楚：git reflog本质是"HEAD指针旅行记录"，它不等于"所有提交的清单"。如果某个提交是通过git commit --amend被打包替换掉的旧版本，它依然会出现在reflog里，但如果你用git fsck --lost-found去扫描，出来的东西和reflog又不完全一样。两者要配合用，我后面会讲。
2.2 git fsck --lost-found：扫描悬空对象
当reflog里找不到你要的东西时，说明这个对象没有被任何ref（分支、HEAD、tag）追踪。此时需要直接扫描对象数据库：
git fsck --full --lost-found # 更精细地只查悬空提交 git fsck --no-reflogs --unreachable这条命令会把所有“没有任何引用指向”的对象列出来，包括不可达的commit、blob（文件内容对象）、tree（目录快照）。
这里有个容易误解的地方：--unreachable跟--lost-found有什么区别？--lost-found在输出悬空对象的同时，会把内容写入.git/lost-found目录，便于直接查看、恢复文件；--unreachable只是列出，不落盘。急救时跑--lost-found更实用。
--no-reflogs这个参数我也特别说明一下——它强制忽略reflog中的引用，只查真正的"孤魂野鬼"。有时候reflog里还挂着指向，但因为某些操作导致对象确实没有被任何分支追踪，默认的--unreachable会把它们排除掉。加了这个参数才能把"已脱离分支但还被reflog记录"的对象也扫出来。我遇到过几次，跑完git fsck --full --lost-found没发现目标，加--no-reflogs --unreachable才找到丢失的提交。
2.3 git stash：被低估的"后悔药保险柜"
git stash在急救场景里有两个用处。一是当你需要临时保存当前工作区改动去做其他操作（比如切分支修bug），结果操作完之后发现之前的临时改动找不到了——其实它就在stash列表里：
# 列出所有stash记录 git stash list # 查看某个stash的具体内容，不会弹出 git stash show -p stash@{0} # 恢复指定stash并保留记录 git stash apply stash@{1} # 恢复并删除记录 git stash pop stash@{0} # 误删了某个stash怎么办？git stash的底层也是一个commit，可以用fsck找回来 git fsck --unreachable | grep commit第二种情况是在救援操作前主动使用git stash做“现场快照”。比如你准备执行一个危险的git rebase，先把当前状态全部stash掉，即使rebase失败搞得一团糟，也能立刻git stash apply回到起点。很多人不知道git stash底层会创建一个commit对象，所以它其实是可恢复的——通过reflog和fsck都能捞到。
3. 工作区和暂存区误操作：文件还没离开仓库
这一层的误操作最频繁，也最容易让人慌：辛辛苦苦改了一下午的代码，一个git checkout .全没了，或者git add加错了文件，再或者git rm误删了不该删的文件。好消息是，这一层的救援成功率是最高的，因为文件内容十有八九还存在于Git的对象库里。
3.1 工作区文件被覆盖：从index和HEAD里捞
场景：修改了文件A，然后手滑执行了git checkout .或git restore .，工作区所有未提交的修改全部被覆盖回HEAD版本。
此时你把工作区翻了个底朝天也找不回修改，因为 checkout/restore 的语义就是用HEAD的内容覆盖工作区——旧内容在哪里？
答案在先前的暂存区或index里。如果你在覆盖之前执行过git add，那旧版本还存在于index对象中；即使没add，只要文件在被覆盖之前曾经被Git跟踪过，HEAD对应的旧版本也还在。
# 查看index中该文件最后一次暂存的内容 git show :文件路径 # 把index里的版本恢复到工作区 git restore --source=:文件路径 -- 文件路径 # 查看HEAD里该文件的内容 git show HEAD:文件路径但实际中更常见的做法是直接用 fsck 扫描悬空blob对象，然后逐个比对内容。因为很多人在git checkout .之前根本没add，工作区修改只存在于Git临时创建的blob对象里，且这个blob在对象库中是不可达的——它不会被任何ref追踪，但只要没被gc，就能扫出来。
大概的抢救过程： 1. 先别覆盖现场，停止一切写操作 2. git fsck --full --lost-found 或 git fsck --no-reflogs --unreachable 3. 在 .git/lost-found/other 下找到一堆没有文件名的blob对象 4. 用 file 命令识别格式，或起个临时文件名逐个 git show 查看内容 5. 找到目标内容后恢复，复制回工作区3.2 reset --hard 把暂存区也冲了：利用悬空对象
git reset --hard是急诊室最高频事故之一。它的语义是：把HEAD指向目标commit，同时把暂存区和工作区全部重置为该commit的状态。这意味着你之前暂存的、未暂存的修改，全部被"打回原籍"——但注意，只是从索引和工作区消失了，里面的文件内容如果曾经被写入过对象库，都还在。
具体判断方法：
# 误操作后立刻跑，看看还有哪些不可达的blob git fsck --full --lost-found # 针对特定路径，查所有包含该路径的悬空提交： git fsck --full --lost-found | grep commit如果找到的是悬空commit，可以直接git cherry-pick或git merge把改动找回来；如果只有blob对象，就得一个个git show <blob-id>看内容。我曾经帮一个程序员同事恢复过一整个下午的修改——他git reset --hard之前把修改git stash了，但随后又git stash drop了，这两连操作下来我把reflog和fsck捞了个遍，最后是在悬空commit里找到了stash的原始内容，整个文件夹从垃圾箱拖了回来。
3.3 误 add 和误 rm：有撤销专用命令就别自己造轮子
git add加错了文件，用git restore --staged即可：
# 解除某个文件的暂存状态，但不影响工作区 git restore --staged 文件名 # 一次性解除全部暂存 git restore --staged .注意这个命令是Git 2.23以后才引入的，老教程里写的git reset HEAD 文件名仍然可用，但git restore --staged语义更清晰，不会误伤其他操作。一个容易踩坑的地方：git restore --staged默认会执行“恢复整个文件内容到HEAD状态”，如果这个文件在暂存区里的内容和HEAD差很远，你只想取消暂存而不想改工作区内容，一定要加上--staged参数并保持工作区不变，或者用git reset HEAD -- 文件名，语义等价但不同场景下我体会git restore --staged更手感清晰。
误删暂存区的文件更麻烦一点，但Index层面删除不会立刻清掉对象库：
# 删除index中的文件（git rm 的本质动作之一） git rm --cached 文件名 # 后悔了，把该文件从HEAD恢复到工作区和暂存区 git restore --staged --worktree --source=HEAD -- 文件名3.4 一个小技巧：commit 前用 git stash 做“全量安全备份”
每次打算做大动作（rebase、 merge、reset --hard 等）之前，在终端执行一次：
git stash push -m "backup-$(date +%F_%H%M%S)" --include-untracked git stash apply git stash drop # 确认备份成功后再提交正式操作看起来多此一举，但在急诊场景里这就是“先打一针镇定剂再动手术”。--include-untracked会把没有被Git跟踪的新文件也保存进去，单靠git checkout .无法找回的那些新创建文件，在这里能安全兜底。
4. 提交记录层的挽救：reset 之后别急着哭，先看清你用错了哪种
4.1 三种reset模式的区别要烂熟于心
很多人急救失败，根因是把reset的三种模式混为一谈。它们的本质区别在于“要重置几个层级”：
| 命令 | HEAD指针 | 暂存区 | 工作区 | 典型用途 |
|---|---|---|---|---|
git reset --soft | 移动 | 不动 | 不动 | 想把多次提交压缩，但保留全部改动在暂存区 |
git reset --hard | 移动 | 重置 | 重置 | 彻底回到某个commit，丢弃之后所有改动 |
git reset --mixed（默认） | 移动 | 重置 | 不动 | 撤销提交但保留工作区修改 |
了解了这个区别之后，救援思路就清晰了：如果你做的是git reset --hard，那就是三重覆盖，必须走reflog/fsck路线；如果只是默认的git reset（mixed），工作区修改还在，最多是把暂存状态清空，本身不致命。
4.2 reset --hard 后悔后的标准救援流程
这是整个急救手册里最高频的场景，给出一个可以直接照抄的流程：
第一步：立即停止写操作
所有能改动仓库状态的命令都不要碰，包括 commit、merge、checkout、rebase、clean。万一不小心又提交了新的commit，reflog记录虽然还在，但会让搜索范围变大，增加恢复难度。
第二步：查看reflog，找到重置之前的commit ID
git reflog --date=iso在输出里找到执行git reset --hard之前的那个commit ID。这个commit就是被“扔掉的”新起点。记下它。
第三步：用分支或tag把该commit拴住
# 方法一：新建分支指向该commit git branch rescue-20240925 <commit-id> # 方法二：创建标签 git tag rescue-20240925 <commit-id> # 方法三：直接在当前分支强制移回去 git reset --hard <commit-id>推荐前两种。因为如果在急救过程中又做了其他操作，当前HEAD会移动，直接用第三种方式可能会把reflog也搞乱。
第四步：确认内容完整
git log --oneline rescue-20240925 git diff rescue-20240925 --stat如果分支和commit的diff符合预期，说明恢复完成。然后再把工作区里的临时文件处理掉。
4.3 误用 commit --amend 后：新提交替换了旧提交，如何找回旧内容
git commit --amend的本质是“用一个新commit对象替代原来的commit对象”，而旧的commit对象会变成不可达对象。找回方法非常固定：
# 查看刚才那条amend的reflog记录 git reflog # 找到 amend 前的commit ID，然后用cherry-pick把改动提取出来 git cherry-pick <旧commit ID>这里的坑在于：如果你在amend之后又做了多次提交，旧commit ID和当前HEAD的base可能不一样，直接cherry-pick会产生冲突。更稳妥的恢复方式是用git rebase --onto或其他方式在新提交基础上重新应用旧提交的diff，但这要视diff的大小而定。简单场景下直接git show <旧commit ID>查看改动内容，手动重新应用，其实是最省心的。
4.4 rebase 中途放弃：origin 分支是你的救命稻草
rebase的时候如果有人中途告诉你"方向不对，别rebase了"，但你已经rebase了几个commit，且git rebase --abort之后发现本地分支变得很奇怪——那是因为rebase操作会临时创建detached HEAD状态，中断后需要手动切换到目标分支。
这种情况的救援路径：
# 先看自己在哪 git status # 如果rebase还在进行中，可以直接abort回滚 git rebase --abort # 如果abort也不对（比如已经reset过），用reflog找到rebase前的commit git reflog | grep rebase我的经验是：rebase误操作最好的救援是“在rebase开始前先创建备份分支”，因为rebase会把所有待处理的commit逐一重新成新commit。没有备份分支的话，reflog依然能救，但你要分辨那一大堆悬空commit哪个是你原来分支的完整历史。一个取巧的办法是，rebase前执行git branch rescue-before-rebase，成本为零，但能省下一大堆判断时间。
4.5 revert 和 reset 的选择：别用急救手术做普通护理
git revert是“正向修复”，它新建一个commit来反向下掉之前某些提交的改动，历史是完整保留的。git reset --hard是“时光倒流”，直接把指针拉回去。
急救手册里我强烈建议：能不reset就不reset，能用revert就用revert。因为reset会改写公共历史，如果分支已经push到远程并被团队成员拉取，reset会让对方的仓库直接进入“目标状态缺失”的混乱局面，产生大量merge冲突。而revert则是用一个新提交“修补”错误，对其他人完全透明。
只有当错误已经push到远程且分支是个人feature分支，同时还没有其他人基于它工作时，reset才值得考虑。
5. 分支层误操作：合并、删除、切换时出的幺蛾子
5.1 分支被删除（git branch -D）
git branch -D删分支确实很可怕，它会同时删除分支指针和对应的reflog。但注意——Git会为分支创建独立的reflog，如果你删的是分支A，在另一个分支B上跑git reflog show A，能看到A分支的提交记录直到删除那一刻。
恢复步骤：
# 查看被删分支的reflog（可以指定其他分支来查） git reflog show 被删分支名 # 或者用fsck直接扫描悬空commit git fsck --full --lost-found | grep commit # 找到该分支最后一个commit ID，重建分支 git branch 恢复的分支名 <commit-id>如果有多个悬空commit，怎么判断哪个是被删分支的最新提交？看commit message、看时间戳、看diff内容，一般都能确认。实在不行，一个个用git show --stat <commit-id>看文件改动。
5.2 merge 合并错了分支：直接把合并提交取消
场景：想在dev分支上合并feature-A，结果手滑把feature-B也合了进来。处理方式取决于“是否已经push”。
未push时，直接reset到merge之前：
# 找到merge之前的commit ID git reflog # 比如merge前是 abc123，当前在dev分支 git reset --hard abc123已push时，推荐git revert -m 1 <merge commit>来创建反向提交：
# -m 1 表示保留merge的第一个父提交（即主分支线） git revert -m 1 <merge commit的ID>关于-m参数的原理简单说一下：merge创建了一个有至少两个父提交的合并commit。revert默认不知道要对比哪个父提交，所以必须用-m 1或-m 2指定。-m 1保留主分支线，-m 2保留被合并分支线。绝大多数场景下我们用-m 1，因为你想要的效果是“保留合并之前主干线上的内容，去掉另一个分支引入的内容”。
5.3 checkout 切分支丢了工作区修改：用 stash 或者 fsck 找回
场景：在A分支上改了一堆文件，直接git checkout B，B分支上这些文件的内容被覆盖。此时A分支的reflog里不会有任何A分支的提交记录（因为你没提交），这些修改只能以悬空blob的形式存在。
处理方法：
# 如果文件是仓库tracked过的，且没有被commit，checkout后可以用index找 git show :路径 # 如果文件既不tracked也不在index，那就必须fsck了 git fsck --unreachable | grep blob # 逐个查看blob内容，恢复目标文件这个场景比较痛苦，因为blob对象没有文件名，所有恢复的内容都很难判断归属。最好的预防依然是stash + include-untracked，防患于未然。
5.4 fetch 更新了远程，但本地分支已经不是原来的：用 remote-tracking 分支找回
场景：本地分支dev基于远程origin/dev进行了多次提交。后来有人重置远程为旧状态，你fetch之后发现本地dev相对origin/dev多出很多“奇怪的commit”，想回到本地原来的状态——但其实你现在的本地分支已经是“混合体”。
处理这种混乱，核心思路是借助origin/dev和本地reflog来分辨哪些是你的原创提交：
# 查看本地dev与origin/dev的差异 git log --oneline origin/dev..dev # 如果diff显示的是不同内容，说明本地被reset过 # 用reflog找到本地dev被reset前的commit git reflog show dev简单粗暴的方法：如果确定远程的origin/dev是正确的基线，那就以它为参考重新建本地dev：
git branch -f dev origin/dev git checkout dev但这会把本地之前所有独特提交丢掉，所以执行前必须确认那些提交已经备份或确实不需要。
6. 三大高频事故的完整抢救案例
这一节我挑三个我实际帮人处理过的高频场景，给出完整的抢救链路和每一步的思考。你可以把它当作急救SOP来对照执行。
6.1 案例一：清晨手滑git reset --hard HEAD~1丢了一小时提交
背景：某同事在feature分支上开发，当天上午写了两个commit，然后准备撤销中间一个commit，一不小心执行了git reset --hard HEAD~1，等于把最近一次commit连带着工作区改动全扔了。
抢救链路：
1. 立即停止所有操作 当时他第一反应是又 commit 了一次，试图把“丢失的内容”写进新提交。 我让他先把终端关掉，禁止继续写。 2. 跑 git reflog 发现最近5分钟有一条记录： abc123 HEAD@{0}: reset: moving to HEAD~1 而 abc123 正是被扔掉的那个commit ID。 3. 验证内容 git show --stat abc123 确认这就是他刚才写的那一两个小时的内容。 4. 恢复 git branch rescue-上午工作 abc123 然后再切回dev分支，把rescue分支合并进来。 这样做的原因是：直接 git reset --hard abc123 也能恢复， 但会丢掉“误操作本身”的记录，如果后面再追查问题就少了一条线索。心得：reflog是整个救援的定海神针，只要你在误操作后没乱搞，十有八九能靠它找到目标commit。
6.2 案例二：git add -A误把大文件全部暂存，随后还 commit 了
背景：项目中生成了一个几百MB的临时文件（比如日志或模型权重），同事执行git add -A时没注意，直接把它加进了暂存区并提交了，然后push不上去才发现问题。
抢救链路：
1. 停止push 本地已经commit，但远程还没接收到，这个阶段最安全。 2. 撤销那个commit但不丢代码 git reset --soft HEAD~1 # 所有改动回到暂存区，HEAD指针后退一个commit 3. 把误加的大文件从暂存区拿出来 git restore --staged 大文件路径 # 之后可以在.gitignore里加上这个文件 4. 重新提交 git commit -m "正式提交" git push如果已经push成功了，玩法就不一样了。远程仓库已经有这个超大文件的历史，就算你把本地重置且重新push，远程历史里还是会有它（除非操作远程仓库权限）。这时需要用git filter-repo或git filter-branch这类历史改写工具清洗历史。这个比较复杂，我的建议是先在本地修改好再git push --force，但要跟团队成员确认没有人在这个分支上工作过。
6.3 案例三：误用git rebase -i压缩错提交，历史一团乱
背景：同事想把最近3个commit压缩成1个，直接git rebase -i HEAD~3，结果编辑器里选错了commit，把不该删的commit标注成了drop，rebase完成后代码成了一个残缺版本。
抢救链路：
1. 立即 reflog git reflog 找到 rebase 起点之前的commit，比如 old-state 2. 对比当前HEAD和old-state的差异 git diff old-state HEAD --stat 你会发现drop掉的commit里的改动全部消失了 3. 恢复的方法有两种： 方法A（粗暴）：直接 git reset --hard old-state，回到rebase前， 放弃这次rebase操作，然后重新小心翼翼地做 方法B（精细）： a) 找到被drop掉的commit ID：git reflog show old-state b) 对这些commit逐一执行 git cherry-pick <commit-id> c) 如果冲突，手动解决后 git commit 我通常推荐方法A，因为rebase的目的已经乱了， 与其在脏数据上续命，不如直接推倒重来，代价更小且更可控。经验：git rebase -i编辑提交列表时，有一步是“保存并退出编辑器”之后、rebase真正开始之前，git会对每个待处理的commit做重复“应用-暂存-提交”。如果你在编辑时发现自己搞错了，可以直接退出编辑器不保存，或者执行git rebase --abort中断，前提是你还没开始应用。这个“abort窗口”是最安全的。
7. 救援死角：跨设备、gc 后的损失，以及为什么有人说"找不回来了"
7.1 为什么网上有些说法说"有些误操作无法恢复"？
因为Git的救援机制高度依赖“对象还在不在”。有两个致命前提：
git gc或git prune执行过后，不可达对象会被立即清理，reflog里的旧引用也会在过期后被清理。- 如果在另一台机器上操作，本地对象库没有该仓库的任何提交数据，当然无法在本地恢复。
第一个前提解释了为什么有些人试尽方法还是恢复不了：他们要么在误操作后跑了git gc（有些IDE或脚本会自动执行），要么时间隔得太久reflog已经过期（默认90天）。
第二个前提则是很多远程协作场景的痛点：你在A机器上误操作，但最新的提交只推到了某个临时分支，而B机器上拉下来的历史不完整——此时唯一可行的方案是找还有完整对象库的机器尝试恢复。
7.2 如果你的提交在gc后没了：还有最后的防线
git gc之后不可达对象被清理，但有一种情况特殊：对象还没被立刻删除，而是进入了.git/objects/pack的打包文件中。git fsck --full在扫描时会输出“unreachable object”信息，即使它被打包了也可能被扫出来。如果你运气好，还能通过git cat-file --batch-all-objects遍历所有对象来找：
git cat-file --batch-all-objects --batch-check | awk '$2 == "commit" {print $1}'然后逐个git show查看。这种方法很粗暴，也很慢，但确实是gc之后少数还能抢救的路径。要注意的是，git cat-file --batch-all-objects输出的对象数量可能非常庞大，尤其是在大仓库里，需要有耐心且有明确的搜索目标。
7.3 被git clean -fd清理的未跟踪文件：还有救，只是难度高
git clean -fd是把工作区里所有未跟踪的文件和目录直接删除。这时候文件根本没有进入过Git对象库，意味着fsck和reflog都救不了它。但有一个不为人知的小通道：如果你在删除之前文件曾被某个stash存过（即使后缀也stal），那还可以通过stash的底层对象找回。
如果完全没有经过Git，那就只能依赖文件系统层面的恢复工具了。这已经超出Git本身的范畴，所以我的建议还是那句老话：高危操作前先git stash push --include-untracked。
7.4 误清空 .git 目录：什么情况下没救
极端情况：整个.git目录被删除或者rm -rf .git。如果仓库本身还保留着本地工作区，还有一线生机——git init新建一个仓库，然后把原本工作区的文件作为initial commit提交进去（但会丢掉所有历史）；如果.git和objects都没了，那历史是真的无法通过Git自身恢复了。
出于安全考虑，建议重要仓库设置定期裸克隆备份，或用git bundle做离线打包。这个不属于急救话题，但确实是每一位程序员都该提前布好的防御线。
8. 建立自己的急救防御体系：这些配置和习惯能让你少踩一半坑
8.1 必开的安全配置
# 修改reflog过期时间，默认90天可能太短，建议半年或永久 git config gc.reflogExpire "180.days" git config gc.reflogExpireUnreachable "30.days" # 别的分支误删时强制启用保护，而不是静默放行 git config branch.autosetupmerge true # push时禁用 --force 单独推送，必须带 --force-with-lease git config --global push.default current # 让git在误删未提交内容时提示（其实是别名，见下）还有一个实用安全配置是设置别名，把容易出错的命令前加一层确认：
# 把reset改成要输入yes才执行 git config --global alias.hard '!git reset --hard "$@" || true; echo "看清楚了？真的要用hard？"'老实说这只是心理安慰居多，但“主动提示”总比“静默栽进去”强。对新手，强烈建议先把git reset --hard从肌肉记忆里删掉，用git restore和git switch代替大多数场景。
8.2 高危操作前的“三秒冷静清单”
我把它做成一个固定动作，刚开始可能觉得很傻，但养成习惯后能救很多次：
1. 这个操作影响范围多大？ - 只动工作区？只动暂存区？还是连HEAD都动？ 2. 有没有备份？ - 最简单的备份：git stash push --include-untracked -m "before-<timestamp>" - 更稳的备份：git branch backup-<timestamp> 3. 如果操作错了，我怎么回来？ - 用git reflog / git checkout <commit-id> - 如果可以，先用 git revert 而不是 reset一次rebase前花5秒创建备份分支，能帮你省下几个小时的恢复时间。我在给团队做分享时总说：“急救手册的目标不是让你成为恢复大师，而是让你尽量少需要急救。”
8.3 push 到远程误操作后：远程分支是最后一张底牌
本地怎么都搞不定了，还有一个终极方案：如果远程仓库（比如托管平台）保留着推送记录或者可用权限，直接去远程看有没有存留旧状态。很多代码托管平台有分支保护、提交记录审计功能，或者管理员可以直接对仓库做恢复操作。
如果连远程也没有，那最后一次机会就是团队成员的本地仓库——任何一个同事的reflog可能还留着这条分支的指针记录。我之前就遇到过这种情况：本地reset彻底搞乱，远程也强制push了新内容，最后是从另一位同事的电脑里找到原始分支持续开发的。所以平时团队有个好习惯很重要：不要把只有一个备份的仓库当作唯一事实来源，尤其不要只在本地留一份。
8.4 日常防御的三件套建议
最后给我的固定建议，直接照做就行：
- 重要仓库开启远程备份，至少每日自动push到另一个私有仓库，防止本地磁盘损坏或误删。
- 每个feature分支都保留reflog记录的时间，设置
gc.reflogExpire为半年以上，这个成本很低但很关键。 - 高风险的reset、clean、force push前，先敲
git status和git stash push -m "before-mistake"。多打几个字符，少熬一天夜，这笔账怎么算都划算。
