山海尽明意下午三点多，团队里的A同学面色发白地跑过来：“我把 review 过的版本覆盖了，强制推送之后评审全没了，怎么办？”这种话我听过不止一次，而且每次下面接的一句，基本都是“还有救吗”。先给你吃颗定心丸：绝大多数情况下，上一个 review 版本的代码并没有消失，只是分支指针换了位置，老提交还躺在 Git 对象库里。真正没救的，是那种误操作之后又继续乱跑命令、甚至手动清过 gc 的人。这篇文章就把“git提交覆盖review版本”这个事故，从原理到恢复、再到团队防护，完整拆一遍。适合所有用过强制推送、或者习惯在评审工具里反复改历史的开发者。
1. 覆盖的本质是分支指针换了方向，提交本身并没有消失
1.1 先纠正一个误解：Git里的“覆盖”不是文件被抹掉
很多人一想到“覆盖”，脑子里的画面是把旧文件用新文件盖住、旧数据被抹掉了。Git 完全不是这个逻辑。一个提交一旦被创建出来，它的作者、时间、提交信息、父提交、目录树快照全部固定下来，谁也没法真的“修改”它。
所谓覆盖，实际上只是某个分支的引用（ref）从旧的提交节点挪到了另一个节点上。分支的本质就是“贴在某条提交链上的一个标签”，给历史改名、改动线、打乱顺序，都只是拿这个标签来回移动。旧的提交节点会变成没人引用的悬空提交，但它并不会立刻消失，而是安静地留在对象库里，直到某次垃圾回收把超过时限的悬空对象扫掉。
这里要插一句：Git 的提交模型里，哪怕你只是改了一行字，提交的哈希值也会完全变化。因为哈希不止包含文件内容，还包括父提交、提交信息、提交时间这些元信息。所以你会发现“明明内容没变，commit ID 却变成了一串完全不同的字符”，这个现象在评审场景里，会成为判断 review 版本到底在哪的关键线索。
1.2 三种最典型的“覆盖 review 版本”操作
我把平时遇到的事故按操作类型分成了三类，大家可以对号入座。
第一种是 git commit --amend。这个命令用来修改最近一次提交，很多人习惯性用它在评审后修补一个格式问题，结果一 push 才发现，评审平台上的版本已经被“换掉”了。原理上，amend 不会真的改旧提交，而是生成一个新提交，让分支指向新提交，旧提交变成悬空对象。
第二种是 git rebase 或 git squash。把几个散落的提交压成一个、或者把分支重新变基到新的主干上，一次性重写了整条链的提交关系。旧的多个提交全部脱离分支引用，评审平台那边自然就丢了原来的 commit ID。
第三种是 git push -f。本地改了历史之后，普通推送会被远端拒绝，因为远端发现这不是快进合并。于是很多人就直接强制推送。远端分支的指针被强行挪动，远端同样也会留下悬空提交。评审平台一般通过 commit ID 或变更集编号来记录 review 进度，commit 链被一换，Review 的归属关系就找不到了。
这里有一个很重要的结论：绝大多数“review 版本被覆盖”的场景，文件内容是好的，只差一个能重新指向它的引用。你缺的不是数据恢复工具，而是把旧提交找出来、重新挂回分支上的操作能力。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. reflog是第一救命稻草：把被本地覆盖的review版本捞回来
2.1 第一时间别乱跑命令，先看 reflog
事故发生后，第一件事不是凭记忆敲命令，而是把仓库切到“冻结状态”。别继续 rebase，别继续 reset，尤其是不要执行 git gc。垃圾回收一旦跑完，长时间悬空的对象会被物理删除，到那时再想找就真的只能靠远端或评审平台了。
接下来使用 git reflog。reflog 是“引用日志”，它记录了分支指针每一次移动的历史，默认保留 90 天。只要在本地发生过 rebase、amend、reset 这些操作，这里都会留下痕迹。输出大概长这样：
bash复制$ git reflog
f0d9e22 HEAD@{0}: rebase (finish): 将 feature-x 变基到 4a8c41b
a3b5c17 HEAD@{1}: rebase (start): checkout 4a8c41b
9c0e7d1 HEAD@{2}: commit: fix: 调整订单状态机边界
4a8c41b HEAD@{3}: commit: feat: 增加超时重试
看不懂输出没关系，核心思路是：找变基（rebase）开始之前、你执行 review 时那些提交所在的位置。如果 commit message 能对上评审平台上的标题，大概率没跑。
2.2 找到目标提交后，先用分支把它的引用钉死
一旦在 reflog 里看到了可疑的旧提交，比如上例中的 9c0e7d1，别急着切过去、也别急着 reset，先做一件事：创建一个独立的保护分支指向它。
bash复制git branch rescue/review-version 9c0e7d1
为什么先建分支？因为只有 reflog 里的悬空提交，理论上会在 reflog 过期后失去保护，最终被 gc 清掉。但只要你创建了一个真实的分支引用指向它，它就从“悬空对象”变成了“被引用对象”，顺利被纳入保护范围。这一步相当于先打个安全绳，之后再怎么折腾都有退路。
我见过不少人在这步犯错：找到旧提交后立刻 git reset --hard，把自己的工作分支切到旧提交，结果发现还要把“覆盖后的新提交”也保留，两边来回切换，最后状态一团糟。正确做法是先备份当前状态、再处理目标状态。
2.3 恢复分支并推回远端，注意普通推送会被拒
确认旧的 review 版本已经用分支挂住之后，再把原功能分支指回旧提交。
bash复制git checkout feature-x
git reset --hard rescue/review-version
如果你想把当前的覆盖后版本也留个底，可以先执行：
bash复制git branch backup/covered-latest HEAD
然后再 reset。这样新旧两个版本都在本地，随时可以切换。
本地操作完成后，推回远端会有一个问题：当前远端分支已经被强制推送到了覆盖后的状态，而本地恢复分支的旧提交不是远端新提交的后代，所以普通 git push origin feature-x 会被拒绝，报 not fast-forward。如果没有跟团队确认，我不会建议你直接 git push -f。正确做法是：
bash复制git fetch origin
git push --force-with-lease origin feature-x
--force-with-lease 的作用是推送前先核对远端引用是否和你本地记录的远端状态一致，如果一致才允许覆盖，如果不一致会拒绝。虽然它比 --force 安全不少，但“恢复 old version”本质上还是一次覆盖操作，所以推送前务必要和一起 review 的同事打好招呼。
2.4 本地 reflog 被清了怎么办：去别人的 clone 里找引用
一个比较容易忽略的周边思路是：本地 reflog 找不到旧提交时，不代表仓库里真的没有。如果说同事B在事故前 clone 过这个仓库，并且他的本地分支还停留在 review 版本的提交上，那你完全可以从他那里把旧提交拉回来。
把同事B的地址加为远端：
bash复制git remote add colleague-b <仓库地址或路径>
git fetch colleague-b feature-x
如果同事本地分支名不叫 feature-x，直接 fetch 指定提交哈希也行：
bash复制git fetch colleague-b 9c0e7d1
这种情况下，只要对方机器上有这个对象，你的本地一样能拿到。而且这种“从同事本地恢复”的办法，往往比 reflog 更保险，因为他的 reflog 和历史可能根本没被动过。
3. 评审平台上的历史记录，往往是你第二道救援通道
3.1 MR/PR 模式的评审平台会留旧 commit 痕迹
如果本地 reflog 已经失效，或者误操作发生在远端之后，另一个有效的恢复渠道是评审平台本身。
主流的代码评审平台大多采用 MR/PR 模式：评审记录挂在“合并请求”或“拉取请求”这个对象上，而不是直接绑定某个分支。当分支被强制推送后，MR 页面通常会出现“commit 被强制更新”的提示，但旧 commit 的信息往往不会完全消失，你可以在页面的 Commits 标签页里看到历史记录。
操作方法很简单：在 MR 的提交列表里找到覆盖前的那一批 commit message，复制对应的 SHA。然后回到本地：
bash复制git fetch origin
git checkout -b restore-review <从平台上复制的SHA>
如果平台允许直接引用该 SHA，fetch 之后就能在本地检出，之后要做的是把这个恢复分支当成新的工作分支继续开发。如果平台不让你直接 fetch 特定 SHA（部分服务为了保护未发布对象会限制），那就走网页上的下载 patch 功能，把旧版本差异下载下来，再在当前分支上手动应用。
这里要明确一个认知：评审平台保存旧 commit 的目的是审计和追溯，而不是专门给你做版本恢复。但就是这个“顺带保留”的特性，在很多事故里成了第二道抢救线。
3.2 Patch Set 模式的评审系统：旧变更集通常在服务器上没删
还有一类团队用的评审系统，逻辑不太一样：每个评审变更下会有多个 Patch Set（补丁集），每次把新的 commit push 到这个评审分支，都会生成一个新的补丁集。老补丁集不会被新补丁集覆盖删除，而是完整保存在服务器上。
所以这种模式下恢复 review 版本非常简单：进入该评审变更的页面，在下拉列表里切换补丁集，找到“收到 review 意见时”对应的那个旧补丁集。页面上一般会有查看完整 diff 的入口，甚至可以直接通过 fetch 命令拉取该补丁集：
bash复制git fetch <评审服务器地址> refs/changes/xx/xxxx/x
这里面 refs/changes/xx/xxxx/x 的路径格式，在评审平台的“下载补丁集”或“获取补丁集”按钮里通常直接能看到。拉下来之后，你得到的就是一个独立提交节点，可以用它重建分支继续操作。
再补充一个实操细节：评审系统的评论和审核意见有些是按行内 diff 记录的，一旦补丁集切换，大部分平台的评论不会跟着迁移到新补丁集上，你得在新补丁集上重新触发一次评审。这意味着“代码内容救回来了”不等于“评审结论救回来了”，通常要重新走一遍 review 流程。这也是为什么预防比恢复更重要的原因之一。
3.3 重建后的推送策略：别死守着旧 commit ID不放
恢复旧提交后，很多人会下意识地想“能不能让 commit ID 和原来一模一样”，这样评审平台上的旧关联就能自动接上。这里泼一盆冷水：不行。
因为 Git 提交的哈希和父提交链是绑定的，只要恢复分支的基线与原来不完全一致，哈希就一定不同。与其花大力气在制造“历史重映像”上，不如接受新的 commit ID，直接把这个恢复分支推上去当新一轮变更处理。评审只看 diff 内容，不会因为 commit ID 变了就说你的代码不正确。
推送方式也建议分成两步：
bash复制git push --force-with-lease origin feature-x
推完之后，去评审平台看看这个 MR/变更下的最新提交是否已经替换成恢复后的版本，再对照一次关键文件的 diff。确认无误后再告诉团队“可以重新开始 review”，并且把恢复前后的 branch 记得在本地各留一条 tag 作为痕迹。
4. 防患于未然：分支保护、force-with-lease与推送前检查
4.1 分支保护规则，把高危操作挡在源头上
能把恢复工作做好自然不错，但更好的状态是从一开始就不让“覆盖 review 版本”成为可能。这个说难不难，就看规则定得多严。
主流的代码托管平台都支持分支保护规则。比较稳妥的配置是：主干分支（比如 main / develop）禁止全部直接推送，合并必须通过 MR/PR，强制推送权限默认设为“不允许”。这样就算某个开发手滑，也不可能把 review 过的版本从主线上强推掉。
有些人会说“我们 feature 分支不怕覆盖”。但评审通常发生在 feature 分支合入之前，如果你在 feature 分支上强推、覆盖了同事正在 review 的提交，一样会出问题。所以更细一点的规则是：所有处于“评审中”状态的分支也不允许强制推送，或者强制推送至少要有指定负责人单独授权。
4.2 把 --force 焊死，习惯用 --force-with-lease
单独把 --force-with-lease 拿出来讲，是因为这个参数能拦截掉大半事故。它和 -f 的核心区别在于：-f 无条件把本地分支推到远端，而 --force-with-lease 推送前会先对比“本地记录的远端分支引用”和“远端当前实际引用”。如果两者不一致，说明远端已经被更新过（比如评审反馈后又有人在上面改了代码），推送会直接报错并拒绝执行。
也就是说，它能防住一种很典型的场景：你基于旧状态做了一堆历史改写，然后想强制覆盖，但远端其实已经推进到了新的提交上。如果直接用 -f，新提交流水般地被你盖掉了；用 --force-with-lease，这个操作会被拦下来，逼着你先 fetch、先看清楚变化，再决定到底要不要覆盖。
所以我的建议很具体：把 -f 从肌肉记忆里删掉，统一用：
bash复制git push --force-with-lease origin feature-x
4.3 推送前检查两件事，十秒钟避免一次大事故
除了平台规则，个人习惯也很关键。我自己的操作习惯非常机械：每次 push 之前，先 fetch 远端，再看一看“我将要推送出去的提交”到底包含哪些内容。
bash复制git fetch origin
git log --oneline origin/feature-x..HEAD
git diff --stat origin/feature-x...HEAD
第一行命令会列出所有“存在于本地、但远端还没有”的提交；第二行会显示这些提交对比远端的文件改动规模。养成这个习惯之后，很多次我都会在半路发现问题：比如发现 commit 数量比预期多了几个，或者 diff 里包含不应该出现的改动。尤其是当你准备对已经 review 过版本进行历史改写时，这两行几乎必然暴露出风险。
另一个低成本的预防动作是改历史前先打一条 tag：
bash复制git tag review-backup-$(date +%Y%m%d) feature-x
git push origin review-backup-$(date +%Y%m%d)
这是一个“完全不用思考”的备份动作，任何人在 rebase 或 amend 之前都可以先执行一遍。tag 一旦推到远端就成了一个不可变的引用，哪怕本地发生再离谱的操作，团队里任何成员都能通过这个 tag 找回当时的 review 版本。
4.4 别乱跑 git gc，reflog 也不是永远都在
恢复流程里还有一个专门要提醒的点：别把系统自动化清理和手动清理混为一谈。Git 默认的 gc 触发条件比较保守，对象库里有大量悬空对象时才会自动跑。但你手动执行 git gc，或者 git prune，那悬空提交就可能被直接删掉。
reflog 默认保留 90 天，这 90 天是你的黄金救援期。如果你在那 90 天内误删了分支、覆盖了 review 版本，对象还在。可一旦 reflog 过期且没有其他引用指向旧提交，那 gc 之后数据才真正烟消云散。所以面对事故，第一原则永远是：先停止所有写操作，确保没有额外 gc 在跑，再开始恢复流程。
5. 每次动历史前，先问自己一句“这条路有没有退路”
说回最开始那个场景。A同学那次最终靠 reflog 把 review 版本找了回来，过程不到二十分钟，之后我在他仓库里看到一条 review-backup-20250115 的 tag。他说以后每次 rebase 前都先打个备份，一分钟的事，但再也不会慌到脸色发白了。
现在我自己习惯了更死板的一套顺序：要改历史，先打 tag；要推远端，先用 --force-with-lease；要重建分支，先给当前状态建 backup 分支。听起来很啰嗦，但 Git 这门工具最大的特点就是你操作得越快，反悔的余地就越小。给错误留退路这件事，成本低到可以忽略，收益却是把“事故”变成“插曲”。如果你现在管理的分支已经在评审流程中，下一次任何形式的 push 之前，不妨也先看一眼这条退路在哪里。