★ FEATURED ARTICLE 上个月半夜我随手敲了一行git reset --hard然后整个人就彻底清醒了想死的心都有。改了三天的分支十几个 commit全都没了。当时第一反应是翻终端历史第二反应是想着要不要给某云厂商客服打电话求恢复快照。最后真正救我命的是五分钟前我还嫌它刷屏烦人的git reflog。直到那一刻我才意识到Git 这个工具真正强大的地方不在于怎么把代码改得漂漂亮亮而在于你把它搞砸了之后还能把它捞回来。这份急救指南就是基于那次事故加上这几年在真实项目里踩过的坑写出来的。我不打算按官方文档给你念一遍命令手册而是按事故场景来文件被覆盖了怎么办、提交搞错分支了怎么办、rebase 中途想放弃怎么办、误删分支怎么找回。每一条都有触发的真实场景有背后的原理还有我自己的实操习惯。看完你会发现Git 里绝大多数“看起来没救”的操作其实都留了后门。1. 抢救之前先搞清楚Git 到底是怎么帮你“留底”的很多人一遇到 Git 事故就慌是因为把 Git 想象成一个数据库删了就没了、改了就被覆盖了。其实 Git 的真实模型要宽容得多它更像一个只会“记录”不会“删除”的记账本。理解了这个底层的记账逻辑急救的方向就清楚了。1.1 Git 的“回收站”其实是对象库Git 在底层把每次提交、每个文件版本都当成一个对象存进对象库库里还有一堆引用refs在“指着”它们。所谓分支不过是一个会移动的指针指向某一次提交。普通用户看到的是main分支、feature分支这些名字但在 Git 眼里真正重要的是那些对象和指针。关键点在这里当你git reset --hard把指针往前挪的时候那棵提交树不是被抹掉了而是变成了一堆“没有引用指向”的悬空对象。它们安静地躺在对象库里除非 Git 的自动垃圾回收git gc把超过一定时间的悬空对象清理掉否则这些数据大概率还在。我打个比方。你写了一份报告发给领导领导看后说不行让你退回上一版。你把文件删了重写但电脑回收站里还留着旧版。Git 的悬空提交就是这个回收站只是它在命令行里看不见多数人也不知道怎么打开。1.2 Reflog 才是急救者的第一现场对象库能告诉我们“数据还在”但没法直接告诉我们“原来的分支指向哪里”。这时候就要看 reflog。Reflog 全称是 reference log说白了就是“引用变动记录”。你在 Git 仓库里做的每一次会移动指针的操作包括提交、切换分支、reset、merge、rebaseGit 都会在.git/logs目录下记一笔账记录 HEAD 或者分支引用从哪个提交移动到了哪个提交。这就意味着哪怕你误删了一个分支、误 reset 回退了十几个提交reflog 里依然记录着“这个分支在出事之前指向的提交哈希”。拿到那个哈希值你就有机会把分支重新捞回来。我那次深夜事故救我的正是 reflog 里的HEAD{5}。注意reflog 不是永久保存的。默认情况下已提交的历史 commit 会保留 90 天未提交的暂存内容保留 30 天。如果你事故发生在很久以前又赶上过git gc那才真正会比较麻烦。后面我会专门讲应对办法。1.3 急救的黄金定律先备份、再动手、不要连着敲命令我见过太多人包括当年的我自己一慌张就连续执行git reset --hard、git clean -f、git checkout .把最后一个可能的现场也破坏了。这里有一条必须刻在脑子里的定律第一任何恢复尝试之前先备份当前状态。不需要搞多复杂一条命令就能做到git status ~/git_status_备份_$(date %F).txt git branch backup/紧急备份_$(date %F_%H%M%S)第二个更彻底一点git tag backup/emergency-$(date %s)标签和分支一样是引用但它比分支更不容易被误操作改掉适合作为急救锚点。别嫌这多此一举多花十秒后面能省掉很多次“刚才那份还能找回来吗”的纠结。第三一次只执行一条命令执行完马上git status、git log --oneline -5看结果。Git 命令不像开关它没有撤消键但每条命令本身都在 reflog 里留了案底所以你可以通过下一条命令来反悔。前提是你至少要知道自己上一步做了什么。2. 文件层面的误操作覆盖、误删、add 错文件先处理最高频的几类事故。这类事故不涉及提交历史的改写操作相对轻量但正因为轻量很多人随手一敲就把唯一的工作成果给埋了。2.1 工作区文件被覆盖或误删怎么弄回来先说场景你改了某个文件改到一半突然想看看原始版本手一抖执行了git checkout -- 某文件或者干脆git restore 某文件改了大半天的内容瞬间消失。如果你的修改从未git add进暂存区也没有提交过东西是不是真的没了严格来说是的。Git 只对已经记录过的内容负责那些只在工作区、从未进过索引的改动任何版本工具都救不回来——这不是 Git 的缺陷是所有版本管理工具的共性。但有一种情况能救你的文件曾经被git add过或者被提交过。这时候git restore和git checkout是拿“暂存区”或者“最近一次提交”里的版本去覆盖工作区文件git checkout -- 文件名 # 老版本的写法从索引恢复文件 git restore 文件名 # 新版本的写法语义更清晰我自己的习惯日常尽量用git restore。动词更精准意思是“把这个文件还原成索引里的样子”不容易像checkout那样一不小心敲成切分支的操作。如果你要恢复到更早的版本也可以从某个具体的提交里取文件git restore --sourceHEAD~2 文件名注意--source配合--staged使用时可以同时重置暂存区和工作区。这个参数组合适合你需要精确恢复某个历史版本文件、又不想动其他文件的时候。实操心得如果改动还没 add又很关键最有效的防守办法是养成“分阶段提交”的习惯。改完一个单元就git add一次哪怕不 commit也等于把版本快照先交给了 Git 替你看管。这样后续救回来的概率会大很多。2.2 误 add 了一堆不该进来的文件这也算事故。你本来只想把 a.py 加进去结果一个git add .把 node_modules、.env、build 目录全带上了。解决方案看你想做到哪一步只是想把它从暂存区撤下来但保留工作区的更改用git restore --staged 文件名。这是新版推荐写法语义是“把暂存区恢复过来”不会动你的工作区内容。整个暂存区全部撤下git reset不加任何参数默认--mixed。这个操作几乎所有 Git 用户都用过理解好它很关键后面的 reset 部分我会展开。有人喜欢用git reset HEAD 文件这是老写法新版里--staged更直白。需要记牢的点是reset --mixed和restore --staged都不改变工作区文件内容只改变“哪些东西在暂存区里”这个状态。所以你可以放心执行。2.3 文件在错误的提交里能不能把某个文件单独“摘”出来这种场景也很常见A 文件的修改混在 B 功能的提交里推到远程才发现。我们经常需要把某个文件从某一个提交里拆出来或恢复到以前某次的版本。如果单纯想“拿某次提交里的某个文件版本”上面说的git restore --sourcecommit_id -- 文件名足够。如果想“把某个文件恢复到上一个提交的状态并保持这个改动是未暂存状态”更自然的做法是git restore --sourceHEAD~1 --worktree 文件名这个命令只影响工作区不会把差异塞进暂存区适合重新整理提交内容。如果你需要把一个错误提交里的文件彻底“开刀”就要进入交互式 rebase 的领域了。但普通用户强烈不建议一上来就 rebase风险偏高先学会相对安全的止血手段。后面第 3 节我再讲 rebase 救援。2.4 提交信息写错了就用 amend但别滥用提交完看到git commit -m feat: tpyo这种拼错的词改信息很简单git commit --amend -m feat: fix the typo--amend不是“修改提交信息”那么简单它的本质是新建一个提交对象替代原来那个提交。所以假如你的旧提交是通过git push推到远程的本地 amend 后本地历史就与远程分叉了。这种情况我一般分两种处理远程只有你自己在用的分支可以直接 force push如果是协作分支千万不要 force push宁可保留错误信息再补一个新提交说明修正。另外一个很容易踩的坑--amend会把暂存区的改动也一起带进新提交。如果你 amend 之前顺手git add了一个不该进的文件它会被一起卷进刚才这条“轻量修改提交信息”的操作里。我的建议是amend 之前先看一眼git status确认暂存区是干净的。3. 提交层级的回退reset、revert 和 merge/rebase 事故文件事故通常只伤皮毛提交层级的事故才是真正让人半夜惊醒的。这一节覆盖 reset 的坑、revert 的正确姿势、merge 和 rebase 的中途反悔。3.1 reset 的三种模式你真的搞清楚了吗git reset的核心理念是指针回退但回退过程中会同时影响三个区域工作区、暂存区、当前分支的引用。模式分支指针暂存区工作区典型用途--soft回退不动不动想重新组织提交保留改动--mixed回退回退不动默认模式撤销 add 操作--hard回退回退回退彻底丢弃改动危险性最高我负责任地说--hard是 Git 急救场景里最常用也最危险的参数。它会把工作区、暂存区、当前分支指针全推到目标 commit。你在--hard之前的改动还没有任何引用的话就真的会被 gc 盯上。那次事故我就是git reset --hard错误地回退了好几个提交。事故之后的正确思路是判断那些丢失的提交还在不在 reflog 里。如果在git reset --hard 原提交的哈希就能一步还原。比如git reflog # 显示 # abc1234 HEAD{0}: reset: moving to xyz9876 # xyz9876 HEAD{1}: commit: 修复登录bug git reset --hard xyz9876回退的提交会因为 reflog 记录而被保留所以你大概率是可以“逆操作”的。git reset --hard ORIG_HEAD这一点很多人不知道。Git 在执行 merge、rebase、reset 这类高危操作时会先把当前分支原来的位置记到ORIG_HEAD。所以git reset --hard ORIG_HEAD常被用来撤销上一步危险操作。它会把你带回“上一步突然变化之前”的状态非常好用。注意ORIG_HEAD 只能记住上一步。如果你连续敲了三四个命令它就是“上一步之前”的位置而不再是你最开始出事的那个点。所以高危操作后立刻备份没事立刻再操作就是个大坑。3.2 已推送到远程的错误提交该怎么办本地 reset 完之后发现远程还是旧状态这意味着你的本地和远程已经分叉。如果分支只有你自己在用可以强推修正git push --force-with-lease origin 当前分支注意我用的是--force-with-lease不是--force。它比--force多了一个保护推送前会检查远程分支是否还是你上次拉取时的状态。如果队友在你拉取之后又推了新东西Git 会拒绝推送并报错避免覆盖别人刚提交的工作。这条是协作场景下的救命符建议直接当成肌肉记忆。但如果是多人协作的分支强推等于把别人的提交从历史上抹掉是会引发混乱的。正确姿势是git revert。git revert HEADrevert 会新建一个“反向提交”把之前那次提交所做的更改撤销掉但不动历史记录。好处是远程历史保持线性队友拉取时不会遇到历史被强行改写的冲突。代价是历史上会留下一条“我撤销了自己”的痕迹。这在实际协作中没什么可丢人的反而说明你做事透明、不藏问题。3.3 误 merge 之后的两条路merge 本身一般不会搞出太严重的灾难因为 Git 在 merge 之前会自动记录ORIG_HEAD。你要面对的无非两种情况还没生成 merge 提交只是碰到冲突不知所措直接git merge --abort一切都当没发生过。已经生成了 merge 提交并且可能已经推到了远程用git revert -m 1 哈希值。这里的-m 1是指定保留 merge 的“主分支”这一支相当于告诉 Git我要撤销这次合并且保留某一侧的历史。git revert -m 1是还原一个 merge 的标准操作。很多初学者在还原 merge 时写git revert 哈希值结果 Git 报错提示“-m或--mainline未指定”那一瞬间才意识到 merge 的还原不是直接套用普通 revert 的。这是我真实踩过的坑今天写出来帮你们跳过。当然如果 merge 还没推远程、也只存在于本地那直接git reset --hard ORIG_HEAD更干净历史里连 merge 的影子都不会留。3.4 rebase 中途想放弃或者已经搞砸了rebase 是把提交“重新铺”到另一个基点上的操作。过程看似优雅出问题时很狼狈冲突连环出现、解决到一半想跑路、甚至 rebase 完发现提交被复制乱套。最稳妥的中途退出方法git rebase --abort--abort会把 rebase 过程完全回退把分支恢复到 rebase 开始之前的状态。只要 reflog 没被手动破坏这招几乎总是有效。另一种情况rebase 已经结束了你发现结果是一堆“假提交”每个提交都被复制了一遍压根不是你想要的铺排。这时候同样用ORIG_HEAD找回原位git reset --hard ORIG_HEAD如果 rebase 是从远程拉取时自动进行的比如 pull --rebase可能你本地产生的提交会被复制。这时可以查看git reflog找到 rebase 前的那个提交位置。通常来说HEAD{1}或者更早的位置就是 rebase 前的点git reset --hard HEAD{1}就能整体退回。实操心得复杂 rebase 前先备份永远是对抗手滑最好的保障。复杂的意思是远程有多个人在推、你自己又攒了一堆本地提交。遇到这种任务我先git branch backup/rebase-$(date %s)然后才开始动手。有这棵“保险树”在怎么折腾都不怕。4. 终极救援reflog、已删除分支与悬空提交前面所有恢复操作都依赖于一个前提你还能找到事情发生前的提交。遇到分支被整体删除、stash 被误弹丢失、commit 被 gc 回收前需要深挖的情况就要动用终极武器了。4.1 读懂 reflog 才是最高频的急救技能先看一个典型的 reflog 输出是什么样子abc1234 HEAD{0}: checkout: moving from main to feature/x def5678 HEAD{1}: commit: 修复按钮样式 123abcd HEAD{2}: reset: moving to HEAD~1每一行包含commit 哈希、定位用标签HEAD{0}表示 HEAD 最近一次HEAD{1}表示上一次、导致引用变化的操作类型、以及操作指向的位置。这个结构非常利于恢复。假设我不小心git branch -D 某分支删了一个包含新功能的本地分支。只要那个分支最后一次指向的 commit 还能在 reflog 里看到我就能这样捞回来git reflog # 找到 feature/xx 分支出没的窗口 git branch feature/恢复分支 abc1234然后把新分支推回远程仓库一切照旧。很多同事当场就喊“天塌了”的分支恢复在 reflog 面前基本就是一行命令的事。另一种场景stash 被 pop 的时候直接跟当前分支内容冲突Stash 当场就“没”了。其实 stash 的提交对象也会被存在 reflog 和悬空对象里。你可以用git fsck --lost-found去挖下面的部分会讲到。4.2 更深的水底git fsck 找回悬空对象如果 reflog 里也找不到说明引用已经不在。但底层对象只要还没被 gc 清理就依然存活。操作对象库的终极扫帚是git fsck。git fsck --lost-found这条命令会扫描对象库把所有没有被任何引用触达的对象列出来并把它们放进.git/lost-found/commit目录。那些 commit 对象可能就是你在找的“已删除提交”。跑的时机有问题吗git fsck是只读操作。我可以很放心地看到任何意外崩溃后执行。需要留意的是执行结果显示unreachable commit不是错误而是未引用对象的意思。上面这个配合 stash 丢失的场景完整操作是git fsck --unreachable | grep commit # 找到一堆 unreachable commit 哈希 git show 哈希值 # 看这个提交是不是丢失的 stash git stash apply 哈希值 # 把它以 stash 形式恢复如果对象被 gc 清理了就没辙了。所以要养成习惯不要长期囤积垃圾缓存但也不要频繁手动git gc干净到把“急救现场”也销毁。默认策略下gc 只清理超过一定时间且不可达的对象大多数紧急情况都能兜住。4.3 找回已删除的远程分支或强制推送覆盖的提交有人误把远程分支删了或者强推覆盖了别人的提交。这种情况比本地分支删除更麻烦因为别人的 reflog 可能刷过去了。靠谱的办法是有权限的同事执行git reflog查远程分支但允许用其本地仓库来捞。本地仓库如果拉过那个分支git reflog show 远程分支名里可能还留着上一次 fetch 时记录的哈希。比如之前 fetch 过origin/feature/xx随后有人强推把远程分支改了。旧哈希可能记在“远程跟踪分支”的 reflog 中。这时可以用git reflog show remotes/origin/feature/xx # 找到旧哈希 git push origin 旧哈希:refs/heads/feature/xx这条命令直接把远程分支重置到旧提交上。但是注意强推远程分支是高风险操作必须通知所有队友确认没有其他人基于新提交在开发。否则你救回旧分支的同时等于删掉了别人的新工作又是一起新事故。4.4 丢失的提交被 gc 清理后还有救吗很遗憾一旦悬空对象被git gc清理、且没有任何备份普通手段救不回来。所以这条我要专门提醒不要手贱高频执行git gc --prunenow。有些开源强迫症用户喜欢每次用完仓库都清理一把那其实等于天天把“急救现场”清空不给自己留退路。如果你的仓库特别大、确实需要主动清理用git gc --prune2.weeks.ago保留合理期限。这样既控制仓体大小又给救援留了窗口期。5. 急救速查表每一个症状对应一条命令好多人生里救急没空读原理我整理了一份我自己的事故速查表全是按真实场景写的。可以先复制保存风险词一到就扫一眼。事故场景立即处理备注工作区文件被覆盖git restore 文件名或git checkout -- 文件名前提文件之前已 add 或 commit误把文件加入暂存区git restore --staged 文件名不会动工作区撤销上一次本地 resetgit reset --hard ORIG_HEAD只对“上一步”有效想找回某个被遗留的提交git reflog查找哈希再git reset --hard 哈希更能改名就用git branch 分支名 哈希已推送的错误提交git revert 哈希团队分支不要用 reset --hard 作用于共享历史合并冲突想退出git merge --abort未生成 merge 提交时可用已生成的 merge 提交被误推git revert -m 1 哈希需要-m参数rebase 中途想放弃git rebase --abort恢复至 rebase 前已删除的本地分支git reflog找到哈希git branch 新名 哈希分支引用在 reflog 里有痕迹stash 被 pop 后消失git fsck --lost-found找哈希git stash apply 哈希尽快操作gc 会真删我建议把这份表贴在终端旁边。没必要背下来但至少遇到事故时能想起“这事有一条处理路径”。5.1 给自己配几个急救别名命令行敲得多了就会想给高频命令起别名。我常用的急救别名长得是这样git config --global alias.undo reset --hard HEAD git config --global alias.last log -1 HEAD --stat git config --global alias.reflog log --oneline --all --reflog git config --global alias.sos fsck --lost-found特别是reflog别名可以一次性显示“所有引用”的 reflog比直接敲git reflog覆盖更广。搜索丢失提交时比只刷 HEAD 记录高效很多。5.2 什么情况才算“真没救”了说实话绝大多数事故都能救只有两种真救不了工作区未暂存也未 commit 的改动在工作区被覆盖且没有备份。悬空对象被git gc --prunenow或等较长时限的 gc 彻底清理又没有远端备份。了解这两条的分界线很重要它能帮你在急救之前快速判断“这个文件还有没有希望”。如果连分支和提交都没丢只是丢了未暂存的工作区内容花时间折腾 reflog 是没用的该找的是编辑器本地历史或者文件恢复工具。方向错了时间就白白浪费。6. 从急救到防御把这套恢复逻辑变成日常习惯急救再熟练也只是亡羊补牢。这几年我越来越明确一个观点Git 救援能力真正值钱的地方不止是“出事能捞”更在于让你对 Git 的每一次操作都更有底所以敢于频繁提交、频繁试验反而是工作流效率的一部分。6.1 提交颗粒度要小提交信息要能定位一个提交只做一件改动信息里写清动机这份责任感在恢复时特别重要。因为 reflog 里只有哈希和操作记录你要确认“这个提交是不是我要的”靠的就是看一眼提交信息。如果它是一个“巨大无比”的提交复盘时会浪费大量时间。一个可参考的提交模式git add 路径到某功能文件 git commit -m feat: 为登录模块增加手机号校验逻辑每次动手前想清楚这次提交在解决什么写成什么样才能帮助“三个月后的我”快速理解6.2 用分支和标签做多层保险我认为有个合理的工作习惯纯本地探索性改动单独开一个分支来玩。就算改到山穷水尽直接git branch -D删掉也不影响主分支。必要时再git tag backup/名称做政策的锚点比如大版本发布前、大重构开始前、跨平台迁移前各打一个轻量标签。代价接近零收益是在想回退时不必靠记忆找哈希。6.3 危险操作前的一个动作就能保命具体到一个可以养成的习惯执行以下任何一句之前先确认 on 哪个分支、备份了没有。git reset --hard git checkout -- . git clean -f git rebase git push --force-with-lease git branch -D我后来给自己定了个规则凡是会“永久改变”当前分支状态的操作开头一律先跑一遍git status git branch # 确认当前分支 git log --oneline -3 # 确认当前位置这三条加起来不到两秒。但这两秒能救你一整晚。6.4 就算不是事故也值得每周翻一次 reflog最后一个建议有点反直觉但我真的会这么做每周花五分钟看一眼git reflog不是因为你出了事故而是为了让这个命令变得“不神秘”。你越熟悉日常 reflog 的常态输出越能迅速发现它哪天表现出了异常模式。等到真出事的时候你不会因为对着一条陌生报错慌了神而是能条件反射地定位到行号找到正确的恢复点。最后再说点实际操作层面的感受。我一直认为Git 急救这东西最稀缺的其实不是命令本身而是“冷静且能持续往同一个方向施救”的心态。多备份、多用 reflog、少强推这六个字我写了这么多年每次自己踩了新坑回来再看依然成立。希望这份攻略能帮你度过凌晨三点那段和 Git 搏斗的时光也希望你永远用不上它。
阅读完成 · 觉得有帮助？
