git误操作这种事凡是写过代码的人多多少少都遇到过。可能是午休回来手一抖把分支 reset 到了一周前也可能是合并的时候顺手 rebase 了一下push 时才被远程仓库一口回绝更常见的是git checkout -- .之后才想起刚才那个文件里有一下午的改动。我见过不少人在群里发一句“我的代码没了谁来救救我”然后一群人围着本地仓库翻 reflog 的场景。这份“Git误操作急救手册”就是给这种时刻准备的。它不是 Git 命令大全也不是讲底层原理的教科书而是一套按事故类型组织的抢救流程什么情况能救、用什么命令救、救不回来的时候还有什么退路。适合刚工作不久的新手也适合那种“明明很熟但总会手滑”的老开发。接下来所有内容我都按实际事故现场来写尽量做到你照着操作就能把损失降到最低。1. 先理清事故类型Git急救的底层逻辑Git 误操作之所以让人绝望是因为它不像普通文件管理器没有“回收站”这种可视化入口。但 Git 大部分操作其实是可逆的只是很多人不知道从哪里下手。急救第一步不是急着输命令而是先判断事故属于哪一档因为不同档位的救援逻辑完全不同。1.1 事故分三档本地未提交、本地已提交、远程已推送第一档是工作区改动被覆盖或丢失比如git checkout -- .、git clean -fd、git stash pop失败之后手滑把 stash 删了。这一档最悬因为改动如果从未被 Git 记录过Git 自己完全没有备份能不能救回取决于操作系统层和运气。第二档是本地已经提交过但还没有推送到远程比如git reset --hard、git branch -D、git amend。这一档基本都能救因为提交对象还躺在对象库里git reflog和git fsck就是你的时光机。第三档是已经推送到远程之后又出问题比如强制推送覆盖了别人的提交、误删远程分支。这一档最麻烦单靠本地仓库不一定能恢复得靠其他同事的本地仓库、远程引用甚至托管平台的备份机制配合。判断完档位之后要立刻给自己立两条规矩第一别再执行任何会改写历史或清理仓库的命令尤其不要跑git gc和git prune它们会真把悬挂对象清理掉第二如果误操作发生在刚打开的终端里先别关终端命令历史里往往还留着关键 commit 的 hash。1.2 急救三件套reflog、fsck、stash我在处理 Git 事故时永远先摸这三个工具它们占到了救援场景的九成。工具作用适用场景git reflog记录 HEAD 和分支引用的每一次移动reset 之后找回之前的 commitgit fsck --lost-found扫描对象库里的悬挂对象reset、stash drop、branch 删除后的对象找回git stash临时保存工作区的改动状态切换分支前保存进度也可以做低成本备份git reflog可以理解成“引用移动的日志”。每次你commit、reset、checkout、rebase、mergeGit 都会把旧位置的 commit 记录下来。git reflog打开以后你会看到类似HEAD{0}、HEAD{1}这样的条目数字越小代表越近。git fsck则是扫描整个对象库找出那些没被任何分支、tag、reflog 引用的对象。它更像“地毯式搜索”适合 reflog 里也找不到的情况。git stash其实是把工作区改动做成了一个特殊的 commit 对象所以它也不算完全独立的机制但它是被误删的高发区域必须单列。三件套配合使用的核心思路很简单能定位 commit 或对象 hash就把它恢复到某个引用上恢复不了 hash就只能走文件系统层面的救援。下面我会按具体场景展开。2. 本地改坏与误删找回提交和恢复工作区本地事故是最高频的也是最能体现 Git 值得信赖的部分。这一章节覆盖 reset、checkout 覆盖、删分支、amend 这四类典型操作。2.1reset --hard手滑reflog 就是时光机某开发者 A 同学在周五下午想把 bug 分支重置到两天前某个稳定点手一抖执行了git reset --hard 2d3e4f5这是一个虚构的占位 hash然后发现这周的提交全都不见了。他当时脑子一片空白群里喊救命。实际上只要他输入git reflog就能看到类似这样的输出2d3e4f5 HEAD{0}: reset: moving to 2d3e4f5 9a8b7c6 HEAD{1}: commit: 修复登录逻辑 7f6e5d4 HEAD{2}: commit: 调整接口参数 ...HEAD{1}就是 reset 之前 HEAD 所在的位置也就是包含了所有“丢失”提交的那个版本。恢复动作极其简单git reset --hard HEAD{1}如果 reset 已经是好多天前的事reflog 里可能翻了十几条那就找那个看起来最能对上的 commit hash或者用git log -g看每个 reflog 条目对应的完整提交信息锁定目标后直接git reset --hard sha。这里有个容易被忽视的细节git reset --hard回退之后之前分支上的提交并非真被删除它们只是在 reflog 里变成了“不活跃”状态。只要你没有在 reset 之后又让 Git 跑过 gccommit 对象都在。所以即使 reflog 被过期清理了还可以用git fsck --full --no-reflogs --unreachable | grep commit去对象库里搜找到 hash 后同样能救。如果 reset 之后你又做了新的提交不想粗暴地把分支指针移回去那就别用reset --hard覆盖改成把丢失的提交基于当前分支打回来。比如 reflog 里找到老提交为9a8b7c6先git branch 临时救援分支 9a8b7c6再到当前分支上对比把需要的改动用git cherry-pick逐一弄回来。这样能保住 reset 之后的新提交代价是稍微繁琐一点但更稳。2.2 工作区改动被覆盖fsck --lost-found搏一把比 reset 更常见的误操作是git checkout -- .或者git checkout -- 某个文件想放弃本地改动改完才发现那个文件里其实存着没保存的关键代码。这种场景很多人会直接崩溃但其实还有一条不大被人知道的退路如果你在改动之后、覆盖之前做过git add那么 Git 对象库里已经存过这个文件的快照覆盖之后它只是变成悬挂 blob。操作流程是这样git fsck --lost-found输出里会有一堆dangling blob开头的行每个后面跟着一个 hash。blob就是 Git 内部存储的文件内容对象。把这些 hash 挨个看内容git cat-file -p blob-hash如果找到想要的内容就把它重定向写回文件git cat-file -p blob-hash src/某个文件.jsgit fsck --lost-found还会在.git/lost-found/other目录下把无法确认归属的 blob 全倒出来你可以直接去这个目录里按文件内容翻找。我处理过的真实案例里有一次就是靠这个目录找回了一份没来得及提交的接口文档。需要说明的是这个方案只适用于“改动曾经被 Git 见过”的情况也就是至少执行过git add。如果是从未被 Git 跟踪的未跟踪文件或者改了以后从来没 add 过Git 对象库里没有记录它就真的只能靠 IDE 的 local history、操作系统快照、文件恢复工具这些外部手段了。所以在我的习惯里写复杂改动前喜欢先git add一下等于给文件买个保险反正后面还能继续改。2.3 分支和标签被误删从引用日志里捞回来分支被删有两种常见姿势git branch -D feature强制删除或者git checkout -B强制重置一个已有分支。不管哪种分支里的提交都还在对象库里。恢复分支的核心就是拿到原来的 commit hash。如果删除前你还对那个分支做过任何操作git reflog show 被删分支名可能有记录如果分支创建自某个旧 commit那它的提交就不能在其他分支的 reflog 里了就用全局命令找git reflog show --all | grep 特征关键词 git fsck --full --unreachable | grep commit拿到目标 hash 后直接重建分支git branch feature 4f5e6d7标签被删也是同样思路。删除标签后git show-ref --tags里当然看不到了但git fsck --unreachable还是能发现悬挂的 commit 对象找到对应 commit 后重新打标签git tag v1.2.3 commit-sha。有一点要提醒如果误删的分支上有你后来合并时重写过的新提交而本地没有其他引用指向它尽快在处理前把 shell 历史里出现的 hash 截图留存防止 gc 自动清理。2.4 提交完发现漏了文件何时能动用amendgit commit --amend是新手最容易踩坑的命令。它本来的作用是“修改最后一次提交信息”或者把漏掉的小改动并入上一个提交。比如你刚提交完发现少加了一个配置文件那么git add 配置文件 git commit --amend --no-edit这是没问题的前提是这个提交还没推送或者只有你一个人在用这条分支。一旦提交已经 push 到远程amend 就等于重写了历史任何其他人拿到的旧提交都会和远程对不上团队里会出现难以解释的冲突。如果已经推送了正确的做法是再补一个普通提交而不是 amend。用后续提交去补充内容虽然提交记录里会多一条但推送顺畅也不坑别人。如果你实在很在意提交历史干净宁可走git reset --soft HEAD~1把上一次提交“拆开”重新组织文件后再次提交也要避免在共享分支上 amend。另外提醒一句amend 之后原来的提交对象就变成悬挂的了。你恢复旧提交可以用git reflog或者git fsck但要想清楚到底要不要恢复别把一个新 commit 和一个旧 amend 对象搞混导致历史出现重复内容。3. 合并、变基与挑拣事故现场合并和 rebase 是 Git 事故的重灾区因为它们涉及多个提交的交叉和移动。很多人遇到冲突的第一反应是慌然后开始乱试命令最后把好好的工作区搅成一锅粥。3.1 合并冲突三条路线一条后路合并冲突本身不是事故事故是指你在冲突里迷了路不知道该保留谁、该放弃谁甚至把本来没冲突的文件也弄乱了。处理冲突有三条标准路线。第一条不解决直接跑。如果合并过程中觉得风险不可控或者切进去才发现合错分支用git merge --abort就可以干净地回到合并之前的状态。注意是合并之前的状态不是你合并过程中手动改过的东西所以如果你已经手动改了多个文件跑abort会丢掉这些手动成果要三思。第二条手动解决。Git 会把冲突区域标记在文件里用、、分隔。你逐个文件编辑确认保留哪部分然后git add file标记为已解决最后git commit生成合并提交。这是最稳的方式前提是你清楚两边的逻辑。第三条一键选择某一方的版本。对某个冲突文件执行git checkout --ours 文件 git add 文件或者git checkout --theirs 文件 git add 文件这里最容易搞反的是ours和theirs到底指谁。在 merge 过程中ours指当前分支执行 merge 时所在的分支theirs指被合并进来的分支。如果你是想“保留对方分支的新实现”那theirs往往才是你要的。个别 IDE 的交互式界面会把这两个词翻译得不太准确还是以命令行为准。还有一个常见误区是解决完冲突后执行git commit --amend。合并时 Git 会生成一个合并提交如果你恰好在上一条 commit 附近--amend会把合并提交和之前的提交搅在一起历史会变得很难看。正确的做法是直接git commit不要带--amend。3.2 rebase 进行到一半想反悔abort 与 reset 双保险rebase 的本质是把当前分支上从某个起点开始的提交在新的基线上重新放一遍。它比 merge 复杂因为每一步都会生成新的 commit 对象中途遇到冲突时Git 是停在一个悬空状态。如果你在 rebase 过程中遇到一堆冲突觉得这条路走错了直接放弃git rebase --abort--abort会把分支指针恢复到 rebase 开始前的位置工作区也恢复不会留下半成品。它比git reset --hard温和得多因为只针对 rebase 期间的状态。如果你 rebase 已经完整跑完但后来发现结果不对劲比如合入的新代码把测试搞挂了想退回 rebase 之前git reflogrebase 之前的分支位置通常紧挨在 rebase entry 的上一条也就是HEAD{n}中某个位置。锁定后git reset --hard HEAD{n}注意这里你退回的是“rebase 之前的位置”而非 rebase 之后某个冲突处理中途的位置两者在 reflog 里都可能有记录别选岔了。更稳妥的做法是 rebase 前先在关键提交上打个临时 tag比如git tag backup-before-rebase出问题直接git reset --hard backup-before-rebase不用翻 reflog 猜。3.3 cherry-pick 选错或后悔撤销的两种姿势cherry-pick 是把某个提交“复制”到当前分支来。最常见的坑是选错提交或者挑过来之后发现代码跟当前分支不兼容。如果 cherry-pick 中途就冲突了直接用git cherry-pick --abort这条命令会放弃本次 pick回到 start 前的状态。如果 pick 已经成功但事后反悔有两个选择。选择一用 revert 做反向提交git revert 那个提交的 sharevert 会产生一个新提交把那个提交的变更反向撤销。它的优点是完全不动历史远程和别人都不会出问题缺点是你会在日志里看到一对“提交 反向提交”有的人觉得丑但它非常安全。选择二如果 cherry-pick 是你最近一步操作你确定后面没有新的提交直接git reset --hard HEAD{1}这样可以让分支回到 pick 之前。假如你连续 cherry-pick 了三个提交想全部撤销就先看git reflog找到 pick 开始前的那个位置再 reset。不要只按顺序找 HEAD{1}因为你可能已经在中间做过别的操作。还有一个容易被忽略的点如果你用了git cherry-pick --no-commit把多个提交的内容混合到一个暂存区然后一次性 commit这时代码的“来源”已经打散了。想撤回时不能只 revert 最后生成的 commit因为 revert 会把这个组合提交整体撤销而不是拆回原来的多个提交。遇到这种情况最实用的办法是 reset 到组合提交之前重新来一遍。4. 远程仓库事故推送被拒与覆盖线上远程事故最考验心态因为涉及的人不止你自己。push 被拒、强推覆盖、误删远端分支一旦发生轻则害同事重新拉代码重则把别人没推的提交弄丢。4.1 push 被拒并不一定是坏事git push报错形如! [rejected] main - main (non-fast-forward)很多人第一反应是强推。但 push 被拒其实是 Git 在保护你远端正包含本地没有的提交如果你直接覆盖远端的那些提交在团队里很可能就消失了。正确的处理流程是先看远端到底有什么git fetch origin git log --oneline origin/feature..HEAD git log --oneline HEAD..origin/feature第一条命令列出本地多出的提交第二条列出远端多出的提交。如果远端多出的提交不是你要的说明有人在你之前推了新东西你需要在本地把它们合进来再推送git checkout feature git pull --rebase origin featurepull --rebase会把本地未推送的提交放到远端新提交的后面历史是一条直线推送时就不会被拒了。如果 rebase 过程中有冲突继续参考上一节的处理方式。如果你发现远端那些新提交确实应该替换那才考虑强推而且要格外小心。4.2 强推覆盖线上提交后的急救假设一个场景某同事在功能分支上做了一堆提交另一个同事基于这个功能分支又做了自己的提交然后手滑把功能分支强推到了自己的旧版本。功能分支上原本包含俩人的工作成果强推之后远端只能看到旧版本。此时 GitHub 上直接看的话那些提交似乎“从世界上消失了”。救这种场景需要找任何手里有那份完整历史的本地仓库。Git 的提交对象是分布式的只要团队里任何一个人之前 pull 过这个分支他的本地仓库就藏着对象。第一步先在幸存者的本地仓库里找分支记录git reflog show origin/feature git fsck --full --unreachable | grep commit把找到的疑似 commit hash 逐一用git show --stat sha检查找到那个包含两人提交的版本。第二步用这个 commit 恢复一个救援分支git branch 救援分支 sha第三步对比救援分支和当前远程分支的差异把需要的变更合回去或者直接把远程分支重置到救援分支然后让团队确认。最后推送git push origin 救援分支:feature如果很不幸所有人都重新 clone 过没有任何本地仓库留底那就只能指望托管平台的审查记录、Webhooks 日志或者服务端的镜像备份了。这也是我在带团队时会建议开启“分支保护规则”的原因——对 release 主分支和重要 feature 分支直接禁止强推不给手滑留机会。4.3 误删远程分支远端对象还能捞回来吗误删远程分支的操作一般是git push origin --delete feature很多人执行完才拍大腿。好消息是在你本地refs/remotes/origin/feature这个远程跟踪引用还留在仓库里直到你执行 fetch 或 push 时可能被清理。先看本地是否还留着一份远程分支记录git branch -r如果有origin/feature那很大概率可以恢复。基于它创建本地分支git branch feature origin/feature然后重新推送git push origin feature只在git branch -r里已经看不到了就说明远程跟踪引用被清理过。这时退回到git reflog show origin/feature和git fsck --unreachable的组合查询。如果找到了唯一的那个提交同样git push origin sha:refs/heads/feature可以重建远程分支。整个过程的风险在于误删远程分支之后如果有人做了一个git fetch --prune本地的远程跟踪引用会被清掉reflog 记录也可能受影响。所以遇到这种情况第一时间不要急着 fetch先把本地仓库里能看到的 hash 截图、记录再决定是否继续拉取新状态。5. 隐蔽事故与边缘场景有些事故不是天天发生但一旦撞上就让人一头雾水。这一节处理 git clean、stash、子模块和“分支凭空消失”的问题。5.1git clean误删未跟踪文件能救回来吗git clean -fd会删除所有未跟踪文件和目录这是 Git 里最“物理销毁”味道的一个命令。对已经跟踪过的文件被源文件恢复不难但未跟踪文件没了就是没了因为 Git 根本没有记录过它们。如果你在删除前曾经对这些文件执行过git add那 Git 对象库里会有 blob 对象可以通过git fsck --lost-found找回原理与 2.2 节相同。如果完全没有 add 过Git 层面无能为力。唯一的自救空间是 IDE 的 local history、操作系统的时间机器、文件夹同步工具的版本记录或者干脆看终端有没有保留文件内容。我的经验是git clean前永远先用git clean -n预览它会列出将删除的文件清单。另外如果连目录都想删也尽量先git add -A提交一次再切换到临时分支清理这样即使错了也能回到提交点。养成“先备份到 Git再清理”的习惯能少踩不少坑。5.2 stash 被误删或无法 pop对象库里找 stash 提交stash 的机制是把工作区改动包装成一个 commit 对象放进 refs/stash 引用里。git stash drop或git stash clear会删除这个引用但对象并没有立刻消失它变成了悬挂对象。如果你刚执行完git stash drop就后悔最直接的办法是翻 stash 引用历史git log -g refs/stash如果已经 clear那就走git fsck --unreachable | grep commit然后逐个git show --stat sha找出那个带有你工作区改动特征的提交。确认之后可以直接恢复git stash apply sha如果git stash pop时因为冲突失败工作区里文件可能已经变成半融合的状态。这时候别慌你可以先把冲突标记解决掉也可以用一个更温和的恢复姿势git stash branch 临时恢复分支这条命令会根据 stash 创建时的 commit 位置新建一个分支再应用 stash 的改动冲突会以 merge 冲突的形式呈现处理起来比在半路状态里乱切分支安全得多。如果你在 pop 失败后又手滑执行了git stash drop也不要立即放弃照上面的 fsck 流程多数情况下还能救。5.3 子模块状态混乱典型恢复流程子模块事故的特点是外层仓库看得到“脏状态”但你又没改过它。最常见是同事更新了子模块的 commit 指针你在这个子模块目录里误操作了 checkout导致外层报告 submodule 有改动。基础恢复先尝试git submodule update --init --recursive这条命令会把子模块恢复到外层仓库记录的 commit 指针位置。如果子模块目录已经坏到完全不能用也可以直接删掉目录重新初始化rm -rf 子模块目录 git submodule update --init --recursive有个细节很多人不知道在子模块目录内部执行git reset、git stash、git checkout只影响子模块自己的仓库不影响外层。外层仓库只会关心子模块当前 checkout 的 commit 和它记录的一致不一致。所以遇到“外层状态脏”时先看子模块内部的git status找回内部记录再同步。如果git submodule update报找不到某些 commit多半是因为子模块在远端被重写过而你本地对象库里缺少那个旧的 commit。此时要用git fetch --recurse-submodules先把子模块仓库同步到本地再 update。5.4 分支凭空消失用 reflog 全局搜索还有一种非常迷惑的现象我明明建了一个新分支做了一堆提交怎么切回来以后分支名不见了。原因通常是误用了git checkout -B、git branch -D或者 IDE 的 Git 面板点了某个危险按钮。排查第一步看所有本地分支git branch -a如果分支不在列表里用全局 reflog 搜索git reflog show --all | grep 特征提交信息拿到对应 commit 后重建分支。这里有个好习惯分支名无所谓关键是提交内容别丢。如果你记得大致时间可以直接git reflog --dateiso | grep 昨天那种关键词按时间定位 commit。这类事故最大的误区是冲回git reflog主列表里找。git reflog默认只看 HEAD 的移动而分支的变动记录要看分支自己的 reflog或者--all参数才能覆盖全。6. 急救速查表与养成不慌的习惯前面讲了原理和具体操作最后给一张速查表方便真出事时快速定位。另外分享几个我一直坚持的小习惯它们能大幅减少“事故”发生的概率。6.1 一张表速查所有事故事故场景核心症状第一反应推荐恢复方式预防建议reset --hard回退了分支提交变少git refloggit reset --hard HEAD{1}reset 前打 tag或先分支备份工作区改动被覆盖代码没提交但没了git fsck --lost-found从 dangling blob 恢复文件改动前先git add给 Git 留备份分支被删分支列表里找不到git reflog show --allgit branch 名称 sha重要分支上别用-D强制stash 被删stash list 空了git fsck --unreachablegit stash apply sha别用git stash clear合并冲突后迷路文件一堆git merge --abort重新 merge 并冷静解决合并前先看 diff 和 logrebase 后想反悔rebase 完但结果不对git refloggit reset --hard rebase前rebase 前打临时 tagpush 被拒non-fast-forwardgit fetch git pull --rebase重新推送推送前看远端差距强推覆盖了线上远端提交莫名消失找其他本地仓库用 reflog/fsck 恢复并重新 push开分支保护禁止强推误删远程分支远端分支不见git branch -r从远程引用重建再 push删除前确认--delete的含义子模块状态脏外层 status 显示改动git submodule update --init --recursive删目录重新 init更新前 fetch 子模块6.2 五个能减少误操作的小习惯相比出事再急救我更愿意在日常把风险压到最低。下面这些都是我吃过亏之后养成的习惯。第一个习惯是“重要节点打 tag”。不是要求每个 commit 都打而是在做危险操作比如 rebase、reset、merge 大改动之前打一个git tag backup-日期。这个 tag 成本几乎为零但出事的时候能让你直接从一串命令里跳出来不需要回忆 reflog 第几条是什么。第二个习惯是“能不 reset 就不 reset”。多数时候可以用git revert做一个反向提交或者用git switch -c 新分支把当前状态暂时搁置。reset 会改变分支历史改动范围越大受伤面越大。能避免大范围 reset 就避免。第三个习惯是“重要改动先 add”。每写一段比较重要的代码就先git add。Git 对象库就成了你的自动备份。哪怕后面改坏了也能从 blob 对象里捞回一个大致的旧版本成本低到可以忽略。第四个习惯是“push 前对账”。推送之前跑一下git diff --stat origin/当前分支 git log --oneline origin/当前分支..HEAD看一眼 本地比远端多了哪些提交、改了几个文件。这一眼能挡掉很多“推错分支”“推送无关代码”的低级事故。我见过不止一次有人想推 feature-A结果把 feature-B 的提交也带了上去就是因为没看差异。第五个习惯是“强推只认--force-with-lease”。我几乎不用裸的--force它无条件覆盖远端引用等于盲操作。而--force-with-lease会先检查远端引用是否和我本地记忆一致不一致就拒绝推送。多几个字母能挡住很多误覆盖。平时把别名配好比如git config --global alias.fwl push --force-with-lease用起来也方便。我个人处理过的最大一次 Git 事故是在 dev 分支上强推覆盖了团队三天的工作成果。当时没有开分支保护等发现时已经有一半同事 pull 了新状态。最后花了几个小时靠两个同事本地仓库里的 reflog 和 fsck 对象把提交全部找回来一个没丢。但从那以后我给自己定了一条硬规矩凡是有两个人协作的分支一律禁止裸--force并且重要节点必须打 tag。Git 本身并不是一个容易让代码“彻底消失”的工具只要 Understand 它把改动藏在哪些地方误操作大多数只是一场虚惊。希望这份手册能让你在下次手滑的时候先冷静十秒然后把它翻出来照着操作。