Git误操作急救手册：reflog与reset命令实战，从删库跑路到轻松恢复-代码聚汇网

Git误操作急救手册：reflog与reset命令实战，从删库跑路到轻松恢复

Gitrefloggit reset

|难度：普通|阅读约 41 分钟

刚在一台闲置服务器上跑了个 git push --force，看到一串绿色的 "force update" 提示时，我后背一下就凉了——那个分支上，是我连着加了三个通宵的代码。那瞬间脑子里只有一个念头：要是能回到十秒前，打死我也不敲这行命令。

后来呢？后来我用了三条命令把分支恢复原样，数据一行没丢。从"删库跑路"到"虚惊一场"，前后不超过两分钟。

这个脚本、这些命令，就是我这些年踩过无数坑之后，沉淀下来的一份 Git 误操作急救手册。它不是什么高深莫测的魔法，而是一套"早知道该多好"的后悔药。看完这篇文章，你不需要背下所有命令，只需要知道：Git 有一个后悔药仓库（reflog），一段无法抹去的操作日志，以及几个万能的"时间倒流"指令。 无论你是刚装了 Git 还分不清 commit 和 push 的新手，还是已经用 Git 管理团队分支多年的老手，这篇文章里的场景，你大概率都用得上——特别是那些"手一抖就没了"的瞬间。

1. 先把保命符备好：Git 的后悔药机制与核心认知

很多人对 Git 的第一反应是"版本管理工具"，但在我眼里，它更像一个带无限存档的游戏。你在游戏里随便浪，死了还能读档重来，Git 也一样——只要你理解了它的存档机制。

1.1 reflog：那个记录你每一次操作的"黑匣子"

如果你只记一条 Git 命令,那就记 git reflog。

很多人知道 git log 能看提交历史，但 git log 只显示当前分支可达的历史，一旦你用了 reset --hard 回退，那些"被丢掉"的提交在 git log 里就消失了。可是它们在磁盘上并没有立刻被物理删除，Git 会在一定时间内（默认 90 天）保留这些对象，而 reflog 就是通往这些"幽灵提交"的钥匙——它记录了 HEAD 指针每一次移动的历史，包括 reset、checkout、merge、commit、rebase 等所有操作。

举个例子，假设你有这样的 reflog 输出：

code复制a1b2c3d HEAD@{0}: reset: moving to HEAD~2
b4e5f6g HEAD@{1}: commit: feat: 用户模块开发
c7d8e9f HEAD@{2}: commit: fix: 修复登录bug

这表示你刚才执行了 git reset --hard HEAD~2，而 HEAD@{1} 和 HEAD@{2} 就是被"遗忘"的提交。想回去？只需要 git reset --hard b4e5f6g。这就是整个急救手册最核心的原理——所有你以为删掉的东西，其实都在原地等你。

提示：reflog 只在本地有效，它记录的是这个仓库本地 HEAD 的移动历史。如果你在另一台机器上误操作，请立即停止在该仓库的所有操作，然后在本机查看 reflog 恢复。

1.2 HEAD、索引（暂存区）与工作区：理解"丢东西"的三种姿势

要真正会用急救命令，你得理解 Git 内容存储的三个层次：

工作区（Working Directory）：你眼睛看到的、正在编辑的文件。
暂存区（Index/Stage）：你 git add 之后，文件内容被"登记"进暂存区，准备下次提交。
版本库（Repository）：git commit 后，内容永久（相对地）保存在 .git 目录中，有唯一哈希标识。

误操作无非是这三层之间的内容被"搞乱了"或"移走了"。比如：

改乱了工作区的文件，但还没 add → 可以用 git checkout -- <file> 从版本库恢复。
git add 了不该加的文件 → 用 git reset HEAD <file> 把它从暂存区移除，但保留工作区改动。
commit 之后想完全撤销 → 就需要 reset、revert 或修复提交来操作版本库。

你可能会问：这些命令之间到底什么区别？别急，接下来每一个场景我都会带你实际操作。

1.3 急救三原则：先备份、再操作、别慌张

在开始任何急救操作之前，请默念这三条铁律：

先备份当前状态：无论要执行什么 rescue，先把当前分支的状态记下来。最简单的方式是 git branch backup && git stash，或者直接复制一份整个工作目录。
不要随意执行 git gc：git gc（垃圾回收）会清理无引用的悬空对象，也就是你打算"回滚"回去的提交。只要不跑 gc，大部分"误删"都还能找回来。
每次急救操作前，先 git reflog：看清楚每一步的状态再动手，避免二次伤害。

做一个简单的类比：这就像玩俄罗斯方块，你堆的方块快满了，此时的首要任务不是想着消除一行，而是千万不要再按错键让局面更惨。记住这三条原则，你已经赢了一半。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 场景一：还没提交，手滑把辛辛苦苦写的代码清空了

这是最让人心梗的场景，也是我当年第一次接触 Git 急救的真实原因。你花了一下午写的页面样式、调好的接口、写了一半的文档，一个 git checkout . 或者 git clean -fd 全部消失。这时候大多数新手的反应是打开编辑器手动重写——先停一下，让我告诉你什么是真正可行的救援方案。

2.1 工作区文件被覆盖或删除：checkout 与 clean 的"后悔药"

场景演示

假设你手滑执行了：

bash复制git checkout -- src/App.js

App.js 回到了最后一次 commit 的状态，你下午的改动全部没了。这种操作在 IDE 里也偶有发生，比如不小心点击了"Discard All Changes"。

急救方案

如果你还没有关闭终端，马上检查是否能用 reflog 找回？很遗憾，git checkout -- 不会改变 HEAD，所以 reflog 里不会留下痕迹，此时能不能找回，取决于你的编辑器或系统是否有备份机制。VS Code 的本地历史（Timeline）功能有时候能救命，我用它抢救过几次。

如果你不幸执行了 git clean -fd（强制清除所有未跟踪文件和目录），情况更棘手。Git 本身没有直接的 undo 命令，但如果你曾经 git add -N（intent to add）过这些文件，Git 会在索引中留下不可见的"意图记录"，此时可以尝试：

bash复制git checkout -- .

这会把工作区恢复到索引中记录的状态。不过说实话，这招的覆盖率并不高。真正保险的做法，是平时就养成随手 git stash 的习惯，尤其是当你准备执行任何带有破坏性的操作之前。

实操心得：我在重大改动前会先创建一个临时分支：git checkout -b wip/save-point 然后 git commit -m "save point"，之后随便怎么折腾，随时可以回来。这比任何恢复手段都可靠。

2.2 不小心把文件 add 进了暂存区：git reset 的正确打开方式

这个场景我几乎每周都能在群里看到：git add . 的时候没留意，把一堆不该提交的文件（比如 node_modules、.env、密钥文件）放进了暂存区。此时还没 commit，需要把文件从暂存区撤回来：

bash复制git reset HEAD <file>

或者如果想撤出全部：

bash复制git reset

注意，这里的 git reset 默认参数是 --mixed，它只把暂存区的内容回退到 HEAD 状态，但保留工作区的改动。所以你的文件内容不会丢失，只是从"待提交"变成了"未跟踪/已修改"状态，然后你重新调整 .gitignore 再 add 即可。

这个命令我很喜欢拿来说给新同事听——它就像你去超市结账，突然发现自己把不该买的零食放进了购物车，收银员说"没事你放回去就好"，你手里依然拿着零食（工作区），只是购物车里没它了（暂存区）。

3. 场景二：已提交、已推送，如何在"删库"边缘把人拉回来

比上面更惨的是：你不但提交了，还 git push 推到了远程，然后猛然意识到分支上的东西全是乱七八糟的。更惨的是你执行了一条让人悔恨终身的命令：git push --force origin dev，直接强力覆盖了远程分支。此时团队其他人 clone 下来的代码，也就跟着遭了殃。

这可能就是我们题目里"删库"的真正含义——你删的不是"未来"，而是"别人的过去"。所以，本文的重头戏来了。

3.1 撤销已推送的提交：三种姿势，按需选择

假设你有一个提交 bad-commit，你已经推送到了远程分支 dev，现在要撤销它。根据你的需求，有三条路可选：

姿势一：`git revert` —— 添加一个反向提交，最安全

bash复制git revert bad-commit

这会创建一个"反向提交"，也就是把坏提交的改动全部撤销的新提交，然后你正常 git push 即可。这种方式不会改写历史，因此是团队协作中唯一推荐的方式。

优点：不改变历史，远程其他人的仓库不会出现"历史不一致"的问题，不需要强推。
缺点：历史中会留下两条提交（一条错误、一条撤销），稍微有点"丑"。

姿势二：`git reset --hard` —— 永久删除历史，然后强推

如果你确定这个坏提交只在你自己本地出现过，或者你有权限且团队规模小，可以采用：

bash复制git reset --hard HEAD~1
git push --force origin dev

这里 HEAD~1 表示回退到上一个提交，如果你想回退多个，可以用 HEAD~5 或者具体的 commit 哈希。

优点：历史干净，错提交彻底消失。
缺点：远程历史被重写，如果别人已经基于这个分支工作，他们的本地分支会与远程产生分叉，下次他们推代码时大概率会被拒绝，甚至引发更混乱的冲突。要是这时候有人直接 --force 推上去，你的撤销就白撤了。

注意：在团队分支上使用 git push --force，一定要提前在群里喊一声。我见过最惨的案例，一个人 force push 回退了错误的提交，另一个人以为远程坏了，又 force push 回去，两个人互相覆盖了三次，最后只能靠 reflog 一点一点拼回去。

姿势三：`git reset --soft` —— 保留改动，只是撤销 commit

如果你提交后发现漏了文件，或者提交信息写错了，但不想丢掉改动：

bash复制git reset --soft HEAD~1

这会撤销最近一次提交，但保留改动在暂存区，你可以重新调整后再次提交。如果你想保留改动但不想保留暂存状态，用 --mixed（默认）。

我看过很多新手把三个 reset 参数混为一谈，这里给个直白的对比表：

reset 参数	移动 HEAD 指针	暂存区	工作区	适用场景
--soft	是	不动	不动	撤销 commit，保留全部改动
--mixed（默认）	是	清空为 HEAD 状态	不动	撤销 commit + 撤销 add
--hard	是	清空为 HEAD 状态	覆盖为 HEAD 状态	彻底回退，放弃所有改动

3.2 分支删了能找回来吗？甚至可以找回远程被删的分支

这个场景千万别慌。当你执行了 git branch -D dev，以为自己把整个分支连同代码一起"删"了，其实分支本质上只是一个指向某个提交的"标签"，删除分支只是删除了这个引用，提交对象仍然留在仓库里。

找回误删的本地分支

bash复制git reflog | grep <分支名>

通过 reflog 找到该分支最后一次指向的 commit 哈希，然后用：

bash复制git branch <新分支名> <commit哈希>

分支就回来了。

找回被强推覆盖的远程分支

假设远程 dev 分支被别人 push --force 覆盖了，而本地没有该分支的最新状态。此时你需要找到"被覆盖前"的提交哈希，可以通过：

询问相关人员查看他们的本地 reflog；
在 GitHub/GitLab/Gitee 的远程仓库页面上，部分托管平台提供了"查看所有分支的提交记录"功能（如 Gitee 的"动态"页面），有时候能找到历史 commit 的哈希；
如果你们用了 CI/CD 或代码托管平台的 Webhook 日志，里面通常会记录每次 push 的 commit ID。

找到之后，直接：

bash复制git reset --hard <commit哈希>
git push --force origin dev

覆盖回来。这招我救过一个删错的 release 分支，当时悬着的心终于放下的感觉，真的比中彩票还爽。

3.3 远程仓库地址被改错了？如何恢复与重设

还有一个看起来很"低级"但实际很多人中招的场景：误改了远程仓库地址，或者手动编辑 .git/config 时删除了远程信息，导致 git push 时报错。

bash复制git remote -v

先查看当前 remote 列表，如果发现少了或有误，可以重新添加：

bash复制git remote add origin <新地址>
git remote set-url origin <正确地址>

或者更暴力的方式，直接编辑 .git/config 文件，在 [remote "origin"] 下修改 url 字段。不过作为一名老开发，我更推荐用命令操作，少碰手写配置文件——毕竟手写容易引入格式错误，报错时还不好排查。

如果只报"找不到 remote origin"，通常是远程仓库地址被删除了，重新添加即可。如果报错 SSH 认证失败（后面 5.2 节细说），则可能是密钥配置问题，不一定是地址问题，先分清楚再动手。

4. 场景三：改坏了分支历史，如何在不吓跑队友的前提下优雅修复

这一节要聊的是 Git 误操作里"内涵最丰富"的一块：分支乱了、合并乱了、提交信息错了、rebase 中断了。任何一项都够人头疼的，但只要理解背后的原理，解决起来就是"分分钟"的事。

4.1 误把代码提交到了 master，如何剪切到 dev

这是网上高频问题："我本来在 master 上干活，结果代码全提交到 master 了，怎么剪切到 dev 分支？"

第一步，从当前 master 创建一个新分支，保留你的工作成果：

bash复制git branch -m master old-master
git branch dev

解释一下这两条命令的含义：

git branch -m master old-master：把当前 master 分支重命名为 old-master，这样你就留住了"错提交的状态"。
git branch dev 从当前 HEAD 创建 dev 分支（此时 dev 和 old-master 指向同一个提交）。

但你肯定不想要 master 变成 old-master 这样奇怪的名字，所以更标准的操作是：

bash复制git checkout -b dev              # 从当前 master 状态创建 dev 并切换过去
git branch -f master HEAD~1      # 把 master 指针回退一个提交（假设只有最后一个提交需要移动）

这样，dev 包含着你的新代码，master 回退到了你动工之前的状态。然后：

bash复制git push origin dev
git push --force origin master   # 回退远程 master

注意：git branch -f 不能用于当前检出的分支，所以要先切到 dev 再操作 master。如果你要移动多个提交，可以用 HEAD~n 或指定 Commit ID。

4.2 rebase 中断之后，如何全身而退

git rebase 是一个非常强大的历史整理工具，但也是误操作重灾区。常见情况是：

rebase 中途遇到冲突，解决到一半放弃了；
rebase 到一半执行了 git rebase --abort，却发现回不到原来的状态；
rebase 结束后悔了，想回到 rebase 之前。

处理方案：

bash复制git rebase --abort

如果 abort 之后 reset 到错误位置，通过 reflog 找回到 rebase 之前的 commit：

bash复制git reflog

找到类似这样的记录：

code复制f3e2d1c HEAD@{13}: checkout: moving from dev to master

回到 dev 分支并指定之前的 commit：

bash复制git checkout dev
git reset --hard f3e2d1c

实操心得：rebase 最安全的做法是——开始 rebase 之前，先创建一个分支 backup-before-rebase 指向当前状态。几秒钟的事，但能保命。我自己被 rebase 坑过三次之后，就再也没跳过这一步。

4.3 合并（merge）出错：如何干净地撤销

你执行了 git merge dev，结果一堆冲突，或者合并后发现代码直接崩了，还想回到合并之前。两种情况都适用：

如果你还没做任何额外操作，直接：

bash复制git merge --abort

这会取消合并，回到 merge 之前的状态。但如果 merge 已经形成了合并提交（merge commit），需要：

bash复制git revert -m 1 <merge-commit-hash>

-m 1 表示保留当前分支（第一个父提交）的内容，丢弃被合并分支的改动。这是撤销合并提交的标准做法，不要用 reset --hard 去回退已经推送的合并提交，因为别人可能已经在被合并分支上继续工作了。

这个场景我遇到过最糟心的是：两个同事分别 merge 了互斥的两个功能，结果 A 同事回退了合并，B 同事再次 merge 时冲突像滚雪球一样越滚越大。所以，分支合并之前一定要确认大家的代码都在最新状态，并且养成合并前先 git fetch 的习惯。

5. 疑难杂症排查与日常急救的"干货仓库"

到了这一节，我们要把视角从"具体的误操作"拉到更高维度：当你遇到各种 Git 疑难杂症时，如何高效定位和排查。这也是我这些年被人问得最多的一部分。

5.1 git commit --amend 的正确用法与常见误区

这是一个高频命令，它的作用是用新的提交覆盖最近一次提交。最常见的应用场景：

提交后发现漏了文件，想补进去；
提交信息打错了字，想改一下；
想合并最近两个提交。

用法一：补充漏掉的文件

bash复制git add forgot-file.txt
git commit --amend --no-edit

--no-edit 的意思是沿用原提交信息，不打开编辑器。

用法二：修改提交信息

bash复制git commit --amend -m "feat: 修复登录模块的令牌刷新问题"

用法三：合并最近两个提交（进阶玩法）

bash复制git reset --soft HEAD~2
git commit -m "合并后的提信息"

这里解释一下原理：reset --soft HEAD~2 把 HEAD 向后移动了两次，但两份提交的内容都留在暂存区，重新 commit 就是一次提交了。

常见误区：很多新手以为 git commit --amend 会改变上一次提交的内容，这没有错，但它实际上是创建了一个全新的提交（新的哈希），然后 HEAD 指向新提交。所以如果你上一次提交已经 push 到远端，此时再 amend 然后 push 就必须强制推（--force）。如果你的同事已经基于旧提交做了开发，这也会引发链式错误。因此，已推送的提交，尽量别 amend。

5.2 SSH 认证失败、token 失效从哪入手排查

"ssh认证失败 git"在搜索热词里排得很靠前，我太懂这个了。每逢新电脑配 Git，这一关十个人里有八个人卡住。

SSH 方式常见的报错：

Permission denied (publickey)
git@github.com: Permission denied (publickey)（这里请把域名替换为你实际的托管平台）

排查步骤：

第一步，确认你用的是 SSH 还是 HTTPS：

bash复制git remote -v

如果 url 是 git@xxx:user/repo.git 格式，走 SSH；如果是 https://xxx/user/repo.git，走 HTTPS。

第二步，SSH 方式检查密钥是否存在：

bash复制ls -la ~/.ssh/

正常应该有 id_rsa 和 id_rsa.pub，或 id_ed25519 / id_ed25519.pub。如果没有，生成一个：

bash复制ssh-keygen -t ed25519 -C "your_email@example.com"

一路回车，完成后把 ~/.ssh/id_ed25519.pub 的内容复制到托管平台的 SSH 公钥设置里。

第三步，验证是否连通：

bash复制ssh -T git@你的服务器域名

如果是首次连接，选择 yes 接受指纹。如果这一步通过，但 push 时仍失败，很可能是 SSH agent 没加载密钥：

bash复制eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

每次重启电脑后 agent 会清零，所以建议配置 ~/.ssh/config 文件，加上：

code复制Host your-host
    HostName your-server-domain
    User git
    IdentityFile ~/.ssh/id_ed25519

这样就不会每次都要手动 ssh-add 了。

如果是 HTTPS 方式认证失败，多半是 token 过期。在 Gitee 或 GitHub 的"个人设置 / 私人令牌"里重新生成 token，然后在 clone 或 push 时使用它作为密码即可。记住：token 保存好，设置里只显示一次。

5.3 git 目录泄露如何下载？一个需要谨慎对待的"特殊话题"

热词里出现了"git目录泄露如何下载"，这其实是一个网络安全方向的常见话题。我必须首先郑重声明：只有在你对目标网站拥有授权的合法测试权时，才可以进行此类操作。未经授权的"测试"是违法行为。基于合法授权的安全测试场景，这个问题的本质是：

网站存在错误配置，将 .git/ 目录直接暴露在 Web 根目录下，访问者可以通过 https://example.com/.git/ 直接访问 Git 对象文件。这意味着网站源码可能被完整还原。

如果你是一个被授权的安全测试人员，获取源码的通用思路是使用专门的 Git 恢复工具（比如 GitHack、GitTools），它们会通过读取 .git/index、HEAD、objects 等文件，尝试重建出完整的仓库。这里不再展开具体工具的命令行，因为牵扯到安全边界，我不希望任何读者把这类知识用在非法用途上。

合规提示：如果你发现了某个网站存在此类泄露，正确做法是：立即告知站方，或者通过官方渠道提交漏洞报告。不要下载、不要扩散。技术本身没有善恶，但使用技术的目的必须符合法律和道德。

5.4 Windows 环境下的 Git 急救特殊事项

在 Windows 上操作 Git 的读者请注意，有几个特殊的坑，我帮各位提前踩平了：

文件路径与大小写：Windows 默认对文件名大小写不敏感，但 Git 是敏感的。你可能在 Mac/Linux 上创建了 README.md，在 Windows 上又写了 readme.md，这会导致 git status 永远显示文件被修改。建议运行：git config core.ignorecase false。
换行符问题：Windows 的 CRLF 与 Linux 的 LF 不一致，容易导致整个文件显示为被修改。建议初始化仓库时用 git config --global core.autocrlf true（Windows）或 false（Mac/Linux），并统一使用 .gitattributes 规范。
- 一个常见的坑：.gitattributes 里设置了 * text=auto，但老仓库没同步，导致大量文件在 checkout 时被"修正"，git status 一片红。遇到这种情况，可以执行 git add --renormalize . 来一次性规范化。
git open /dev/null or dup failed: no such file or directory：这个报错我第一次遇到时一头雾水，后来排查发现是终端环境（特别是 PowerShell 或 CMD）与 Git Bash 的环境变量冲突导致 stdout 被重定向到不存在的设备。解决方法是不要在 PowerShell 里直接调用 Git Bash 脚本，或者重启终端，让 PATH 环境变量干净一些。
Windows 下删除文件被占用：如果你用 git clean -fd 清理文件，Windows 上可能会因为文件被编辑器或杀毒软件锁定而失败。此时先关闭相关程序，再重新执行，或者到资源管理器中手动确认锁定后删除。
.git 目录过大：很多 Windows 用户会遇到仓库 clone 过大，卡死在某个对象下载，这类问题多半是历史中混入了大文件。删除大文件的历史需要使用 git filter-branch 或 git filter-repo，这里不展开命令，但建议优先考虑用 BFG Repo-Cleaner 工具（比 filter-branch 快很多，也更安全）。

6. 稳、准、狠的日常习惯及一条救命备份命令

最后这部分，三两条硬核技巧 + 一个救命的脚本。我保证这不是老生常谈，而是我用真金白银（时间）换来的经验。

6.1 每次 push 之前必做的几秒检查

养成肌肉记忆级别的习惯：

bash复制git status
git diff --stat
git log --oneline -3

三步只要五秒钟，但能避免 90% 的"删库"事故。

git status 让你知道现在处于哪个分支、哪些文件会被提交；
git diff --stat 让你看改了哪些文件、改了多少行；
git log --oneline -3 让你确认要推送的提交是不是你想推送的。

尤其是多人协作时，通过这三个命令，你能在 push 前就发现"哦，我怎么在主分支上"或者"怎么把别人的代码带上来了"。

6.2 建立安全的推送策略：环境变量 + 强制验证

我给团队成员设了一个"规矩"：主分支（master/main/prod）上，禁止直接 push。实现方式是在仓库根目录 .git/hooks/pre-push 脚本里做分支名校验，阻止向 master 强制推送。以下是一个简化版脚本：

bash复制#!/bin/sh
branch=$(git symbolic-ref HEAD | sed 's|refs/heads/||')
if [ "$branch" = "master" ] || [ "$branch" = "main" ]; then
  if [ "$FORCE_PUSH_ALLOWED" != "1" ]; then
    echo "禁止直接向 $branch 分支推送"
    echo "如需强制推送，请设置环境变量 FORCE_PUSH_ALLOWED=1 并再次尝试"
    exit 1
  fi
fi

这个脚本的思路很简单：无论你是 git push origin master 还是 git push -f origin master，pre-push 钩子都会在推送前拦截，除非显式设置 FORCE_PUSH_ALLOWED=1。它能有效避免"手滑强推了老板的分支"这类事故。

当然这个脚本在 CLI 环境下有效，GUI 工具（如 VS Code、SourceTree）走的不一定是同一个钩子，但多一道防线总比没有好。

6.3 一条救命备份命令（收藏级）

这条命令解决一个问题：你马上要执行一个可能有风险的操作（reset、rebase、force push），先把当前所有状态打包存成一个标签，随时可以回来。

bash复制git tag rescue-$(date +%Y%m%d-%H%M%S)

就这么简单。你随手打一个带时间戳的 tag，如果操作失败，只需要：

bash复制git reset --hard rescue-20250101-153000

就回到操作之前的状态了。标签在本地，不会对团队产生任何影响，操作成功后还可以顺手删掉这个标签：

bash复制git tag -d rescue-20250101-153000

这就像一个保险栓，用时一分钟，但能避免你一天的重写工作。

额外补充一个小技巧：如果你担心误删 tag，可以在 .git/config 里加一行 [tag] 配置，让本地 tag 不被 push 到远端。或者干脆把 rescue tag 放在本地，别 push 到共享仓库，免得污染远程 tag 列表。

写到这里，我想起一个真实的经历：有一回我把一个包含客户数据的配置文件误提交并且推到了 Gitee 上，发现时已经过了三个小时，期间 team 里另外两个人对这个仓库做了多次 pull。我当时脑子里真的闪过"跑路"俩字。但冷静下来，我用 git log --diff-filter=D -- <file> 找到了文件被删除的历史位置，用 git revert 创建了一个反向提交删掉文件，又沿着 reflog 找到了文件在本地最初的版本，确认没有泄露到外部分支后才长舒一口气。那次以后，我不仅养成了上面所有的习惯，还在 Gitee 的 Webhooks 里配置了提交内容关键字扫描——只要有疑似密钥的配置被 push，就会立刻收到告警邮件。

今天这篇急救手册，就是把这种"我经历过、我踩过、我救回来过"的实战经验，拆成场景化的操作指南。Git 本身不会因为你犯过错就惩罚你，它更像一个冷静的账本，每一笔操作都被记录在案。你需要的不是背下所有命令，而是在慌乱时知道：去看 reflog，去找到那个提交，哪怕它看起来已经消失了，它其实还在那里等你。 下次手滑之前，先深吸一口气，想想这篇手册，你的代码大概率能救回来。