峰瑞资本Git最吓人的一刻，不是你敲错命令报了一堆红字，而是你敲对了命令、输出干干净净，然后突然意识到：这命令作用错了地方，或者是作用在了一块不该动的代码上。比如在错误的分支上执行了 git reset --hard，比如把包含密钥的文件提交并推送到了远程仓库，比如 merge 到一半冲突太多想退出却忘了怎么退。多数人的第一反应是上网搜命令，但搜到的答案往往只说“用 reset 回退”或者“用 revert”，根本没解释这两个词的区别，于是更慌了。这篇就是干这个的——把 Git 最常见的误操作场景整理成一份急救手册，每个场景都带着“为什么会这样”的原理和“现在该怎么办”的具体步骤，你可以直接照着敲。
我尽量按“事故现场”来组织：先说你遇到了什么现象，再说你这时的目标是什么，最后一步步操作。命令不是死记的，理解了 Git 的几个核心概念之后，这些操作都很自然。
1. 动手之前，先得明白 Git 撤销到底在撤销什么
Git 误操作急救最核心的一条心法：绝大多数 Git 操作都不是“立刻删数据”，而是“挪动引用”或“改变指针指向”。 理解这一点，你大概率就不会在错误发生时自乱阵脚。
1.1 Git 的三棵树模型
几乎所有 Git 教程都会讲“三棵树”：工作区、暂存区、本地仓库，如果你在跟远程仓库协作，还要算上远程仓库。这四者的关系可以这样理解：
- 工作区（Working Directory）：你肉眼能看到的文件夹，文件在其中被编辑。这里面的内容跟 Git 没有任何关系，直到你执行
git add。 - 暂存区（Staging Area / Index）：执行
git add后，文件的快照被放进暂存区。它像一个“候选区”，标记哪些改动准备进入下一次提交。 - 本地仓库（Local Repository）：执行
git commit后，暂存区内容被固化成一次提交，记录到本地 Git 数据库中。 - 远程仓库（Remote Repository）：执行
git push后，本地提交被推送到远端，成为团队可见的提交。
我把这三棵树理解成两组书架：工作区是桌子上摊开的稿子，暂存区是“待归档”的堆，而本地仓库是已经贴上标签放进柜子的卷宗。误操作发生时，只要东西还在桌子上、或者还在“待归档”的堆上，捡回来很容易；一旦进了柜子，就得靠 Git 的恢复机制往回翻。
1.2 为什么说“误操作不等于数据丢失”
Git 内部有两个“保险机制”：
第一个是 reflog（引用日志）。 Git 会把 HEAD 的所有移动历史记录下来，包括你 reset、checkout、merge、rebase 时移动的方向。哪怕你把分支回退了几十次提交，reflog 里依然留着之前的提交哈希值。只要提交对象还没被垃圾回收（默认 90 天），就能找回来。
第二个是对象数据库（Object Database）。 Git 里的每次提交、每个文件版本都作为对象存放。你执行 git commit 时生成的对象会一直存在，除非 Git 认为“没有任何引用指向它”并且时间超过了保留期。
换句话说：只要你还能在终端输入命令，90% 的“删库跑路”式事故都能在本地找回来。怕的是你慌到把整个 .git 目录删了，或者克隆了一份新仓库覆盖了本地，那才是真的麻烦。
1.3 急救的第一个动作：不是执行命令，而是记录状态
事故发生后，先别急着输命令。先执行下面三条，把现场信息保留下来：
bash复制git status
git reflog
git log --oneline --all --graph
这三条命令分别告诉你：
git status：当前有哪些改动、在哪个分支、有没有未合并的冲突。git reflog：HEAD最近经历了哪些移动，每条记录的哈希值和操作说明会在后面的大段恢复操作中反复用到。git log --all：所有分支（包括那些“看起来已经没有了”的分支）指向哪些提交。
我建议在动手前先把 reflog 的输出复制到记事本里。这个动作成本极低，但能让你在任何操作失败后，依然有最原始的线索可查。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 提交错东西了：reset 和 revert，到底该用哪个
这是 Git 急救中出现频率最高的一类问题：“我把不该提交的文件提交了”“我把大文件提交了”“我想改上一版提交的信息”。这类问题的解决方案，取决于你到底改没改过远程仓库。
2.1 如果只是上一次提交搞砸了：git commit --amend
场景：你刚执行完 git commit，马上发现漏了一个文件没 add，或者提交信息打错了字，或者上一个提交里混进了不该有的调试代码。
如果这个提交还没推送到远程，最优解是 git commit --amend：
bash复制git add 漏掉的文件
git commit --amend -m "正确的提交信息"
--amend 的作用是“重写最后一次提交”：它把你暂存区里的新内容合并进上一个提交，并生成一个新的提交对象。很多人误以为它是“修改提交信息”而已，其实它更强大的用法是“往最后一次提交里补内容”。
注意，--amend 会改变提交的哈希值。如果原来的提交已经 push 到了远程，并且可能已经被别人拉取了，请不要用 --amend，否则会引发分支分叉。这种情况下，建议老老实实新提交一次，或者用下面说的 git revert。
2.2 如果错误提交还没 push 出本地：git reset 的三档选择
git reset 是本地急救里最常用的命令，它的默认行为是“把当前分支的 HEAD 指针往回挪”，挪到什么位置、要挪多远，由参数决定。这里我强烈建议你把下面三个参数记牢，它们对应完全不同的后果：
| 参数 | 影响范围 | 暂存区 | 工作区 | 适用场景 |
|---|---|---|---|---|
--soft |
只移动 HEAD | 保留 | 保留 | 只想撤回 commit，但希望所有改动还留在暂存区里 |
--mixed（默认） |
移动 HEAD 并清空暂存区 | 清空 | 保留 | 撤回 commit，同时让改动回到工作区 |
--hard |
移动 HEAD、清空暂存区、覆盖工作区 | 清空 | 覆盖 | 想彻底丢弃某些改动，回到某个历史状态 |
举个例子。假设你刚才 git commit 了一个包含敏感配置文件的提交，但还没有 push。执行：
bash复制git reset --mixed HEAD~1
（HEAD~1 的意思是“当前提交的上一个提交”，即回退一步）
这条命令执行后，HEAD 指向上一次提交，而这次提交的所有改动全部回到工作区（状态变成“未暂存的修改”）。你可以把敏感文件处理掉，重新 git add 需要的文件，再 git commit。
最危险的是 --hard。一旦执行 git reset --hard HEAD~1，这个提交在工作区里的文件改动会直接丢失。虽然 reflog 里还留着哈希值，但你已经看不到原始文件了。所以在不确定时，宁可用 --mixed 或 --soft，也不要用 --hard。
2.3 如果错误提交已经 push 到远程：用 git revert 而不是 reset
场景：你 push 之后才意识到这个提交有毒。这时如果还在本地做 reset，下次 git push 就会被远程拒绝，因为远程分支和本地分支已经分叉。强行 push 需要加 --force，但 --force 会把别人的提交也一起冲掉，风险极大。
正确的做法是 git revert：
bash复制git revert <commit-hash>
git revert 不会删除历史提交，而是生成一个“反向提交”：即把目标提交的改动全部回滚，然后新增一次提交记录。远程仓库的历史会被这种“添加一个新提交来撤销旧提交”的方式保持线性，别人 pull 的时候也不会遇到冲突。
如果错误提交是很久以前的，而回滚对象又涉及多个提交，你可以连续执行多个 git revert，或者用范围：
bash复制git revert <oldest-commit>^..<newest-commit>
这里的 ^ 表示“该提交的父提交”。这个范围语法会生成多个反向提交，每个提交对应一个被撤销的目标提交。
2.4 经验补充：为什么说 --force 是危险的
git push --force 在 Git 社区里名声不好，不是因为它没用，而是因为很多人把它当成了万能解药。实际上，只要远程分支上有别人新推的提交，你的 --force 就会把这些提交在远程历史里抹掉，对方的本地历史也会因此在下次 push 时出问题。
如果你的情况真的逼不得已需要覆盖远程历史，请优先使用 --force-with-lease 而不是 --force：
bash复制git push --force-with-lease origin <branch>
--force-with-lease 会在推送前检查远程分支的引用是否与你上次拉取时一致，如果不一致就直接拒绝推送。这相当于加了一层保护，能防止你意外覆盖别人的工作。
3. 分支被删、Commit “消失”：用 reflog 的完整抢救实战
“我误删了分支”“我刚才 reset 错了想找回原来的 commit”这类问题的原理相同：不是数据真的没了，而是没有“引用”指向那些提交了。要找回它们，核心工具是 git reflog。
3.1 reflog 到底记了什么
reflog 是“引用日志”的缩写。每当 HEAD 移动，不管是因为 checkout、commit、reset、merge 还是 rebase，Git 都会记录一条日志。它不像 git log 那样展示“当前分支的历史”，而是展示“HEAD 引用过去指在哪里”。
执行：
bash复制git reflog
输出大致长这样：
code复制a1b2c3d (HEAD -> main) HEAD@{0}: commit: 修复登录模块的bug
e4f5a6b HEAD@{1}: reset: moving to HEAD~1
c7d8e9f HEAD@{2}: commit: 添加支付页面
...
每一行左边是这次 HEAD 移动后的提交哈希，右边是操作描述。HEAD@{0} 是最近的日志，HEAD@{1} 是上一条，以此类推。
3.2 恢复误删的分支
场景：你 git branch -D feature-login 删掉了一个分支，然后发现这个分支上还有一些未合并的独特提交。
恢复步骤：
bash复制# 1. 查看 reflog，找到 feature-login 分支最后一次指向的提交哈希
git reflog
# 输出里找 branch: 或 checkout: 相关记录，记下对应的哈希值，比如 a1b2c3d
# 2. 从那个哈希重新创建分支
git checkout -b feature-login a1b2c3d
如果你删分支之后没有做过其他操作，这个哈希通常很显眼。如果做过很多操作，reflog 记录会很多，但你依然可以通过筛选来找：
bash复制git reflog | grep "feature-login"
3.3 找回 reset --hard 之前的状态
这是我最常被问到的一个场景：我执行了 git reset --hard HEAD~3，发现回退过头了，怎么办？
同样用 reflog：
bash复制# 1. 查看最近的 reflog，找到操作之前的 HEAD 位置
git reflog
# 假设看到类似：b2c34d5 HEAD@{2}: commit: 这是我想回去的状态
# 2. 直接把分支指回那个状态
git reset --hard b2c34d5
这里我特别提醒：如果你在 reset --hard 之后又做了新的提交，reflog 里旧的提交还在，只是排列顺序更靠后。只要它没有被垃圾回收，你随时可以跳回去。
3.4 如果 reflog 里也找不到目标提交
Reflog 有保留期限：一般情况下，HEAD 的 reflog 记录默认保留 90 天，而分支的 reflog 保留 30 天。如果你发现某个提交已经不在 reflog 里了，还有最终手段——git fsck：
bash复制git fsck --lost-found
这个命令会扫描对象数据库中所有没有被引用指向的提交对象，并列出 dangling commit 或 dangling blob。这些对象就是“被孤儿化”的数据。你可以逐个查看：
bash复制git show <hash>
找到目标提交后，同样用 git branch <新分支名> <hash> 或 git reset --hard <hash> 恢复。
3.5 一个重要的安全意识：reflog 不是无限的
Refflog 虽好，但别把它当成日志保险箱。如果你不仅误删了分支，还顺手执行了 git gc，或者本地仓库时间已经很长，一些早期对象可能已经被清理。所以我的习惯是：一旦执行可能改变历史的重型操作，立刻记下当前分支的 HEAD 哈希，甚至直接 git push 前先建一个临时备份分支：
bash复制git branch backup/yyyy-mm-dd
这个备份分支不删，等你确认几个星期后没问题了再清理。成本几乎为零，但遇到问题时，它就是你最安心的后路。
4. 工作区被搞乱、暂存区被误清：restore、checkout、stash 的正确打开方式
这类事故不像“误删分支”那样轰轰烈烈，但痛苦程度一点也不低：你可能本来只改了两行代码，结果一条命令把整个文件变成了别的版本；或者不小心把还没 commit 的改动全放进了 stash，又错误地清空了 stash 列表。这节把工作区和暂存区的几种高危操作拆开讲。
4.1 撤销工作区的改动：checkout 与 restore
如果你在文件里改了一堆东西，现在想回到最近一次提交的版本：
bash复制git checkout -- <文件名>
或者新版 Git 推荐的写法：
bash复制git restore <文件名>
两者效果相同：用暂存区或 HEAD 中的文件内容覆盖工作区文件。注意，这种操作是不可恢复的——如果你没有提前把改动提交或 stash，一旦覆盖，工作区里的修改就彻底没了。
所以我要特别强调：执行这条命令前，先想清楚这个文件里有没有你还没备份的改动。如果你不确定，先复制一份到别的地方，或者用下面说的 git stash。
4.2 撤销暂存区的操作：restore --staged 与 reset
场景：你执行了 git add .，把一堆文件加进了暂存区，然后发现其中一些文件不打算提交。此时有两种办法：
bash复制# 方法一：restore --staged，只取消暂存，不影响工作区
git restore --staged <文件名>
# 方法二：reset，不带参数默认是 --mixed
git reset HEAD <文件名>
这两种方式的效果基本一致：把文件从暂存区移回工作区，文件内容保持不变。它们跟 git reset --hard 有本质区别——后者会连工作区文件一起改，而前者不会。
4.3 stash 误操作：pop 冲突、误删 stash
git stash 是一个极其实用的“临时储藏”工具，但很多人对它的机制不完全熟悉。当你执行：
bash复制git stash
当前的改动（包括暂存区里的内容）会被打包成一个 stash 条目，工作区恢复到干净状态。之后你执行：
bash复制git stash pop
会将最近的一个 stash 条目重新应用到工作区，并从 stash 列表中删除该条目。
问题来了：如果 pop 时遇到冲突（比如你切换分支后，目标文件已经被别人改过），Git 会保留 stash 条目而不删除，同时把冲突标记留在工作区。这时你可以手动解决冲突，然后执行 git stash drop 清理：
bash复制git stash drop stash@{0}
如果你执行了 git stash clear，清空了所有 stash 条目，但是没 pop，这些条目也不是彻底消失，可以用 git fsck 找回。具体操作：
bash复制git fsck --no-reflogs | grep commit
这会列出所有未被引用但还存在的提交对象，挨个 git show 筛选出你要的那个 stash。
4.4 还有个容易忽略的命令：git restore 的源头参数
新版 Git 的 git restore 比 checkout 更精细，因为你可以指定 restore 的“来源”：
bash复制# 从 HEAD 恢复（也就是撤销所有未提交的改动）
git restore --source=HEAD <文件名>
# 从某个具体的提交恢复
git restore --source=<commit-hash> <文件名>
它比 git checkout -- 多出的优势是：你可以从任意提交里取文件覆盖当前工作区，而不用手动切换分支。这在“我误删了某个文件，但这个文件在之前的提交里还存在”的场景中非常有用。
4.5 实践总结：工作区急救的命令选择表
| 目标 | 命令 | 风险 |
|---|---|---|
| 撤销单个文件的未提交改动 | git restore <file> |
高风险，改动不可恢复 |
| 取消暂存但保留改动 | git restore --staged <file> |
低风险 |
| 临时储藏所有改动 | git stash |
低风险 |
| 取出 stash 并删除条目 | git stash pop |
中等，可能冲突 |
| 取出 stash 但保留条目 | git stash apply |
低风险 |
| 找回误删的 stash | git fsck --no-reflogs |
中风险，需人工筛选 |
我的建议是：如果一个操作的后果你还没想清楚，就先做“低风险”的那一步。宁可在工作区多留一会儿，也不要让文件彻底消失。
5. merge 到一半翻车：如何安全地退出冲突现场
合并是 Git 里最常出事故的操作之一。你可能想把 develop 合并到 feature，结果冲突文件遍地开花；也可能 merge 完才发现合并错了分支，想撤销。这节讲的是合并现场的急救。
5.1 冲突进行中想反悔：git merge --abort
场景：你执行 git merge feature-test，结果一堆冲突，你不想手动解决了，想回到 merge 之前的状态。
bash复制git merge --abort
这条命令会恢复你执行 merge 之前的分支状态和工作区状态，并且不会有副作用。它适用于“merge 尚未完成”的情况，即 merge 已经开始但还没有生成 merge commit。
如果 merge 时已经进入了一种“手动解决冲突中”的状态，--abort 依然有效。它会直接放弃这个 merge，一切回到执行 merge 之前。
5.2 合并完发现错了：git reset --hard ORIG_HEAD
Git 在执行 merge、rebase、pull 这类“会改变 HEAD”的操作时，会记住操作前的 HEAD 位置，保存在 ORIG_HEAD。
场景：你 merge 成功了，但在测试时发现这个合并是错的，想回到 merge 之前：
bash复制git reset --hard ORIG_HEAD
ORIG_HEAD 就是 merge 之前的分支头部。执行这条命令后，整个分支会回到 merge 之前的状态，merge 产生的提交会被丢弃。注意，--hard 会同时清空工作区，所以执行前确认 merge 之后你没有留下需要保留的改动。
如果你已经把这些 merge commit 推送到远程了，就不应该再用 reset，而应该用 git revert 撤销这次 merge。撤销 merge 提交和撤销普通提交不同，因为它有两个父提交，需要指定要保留哪个：
bash复制git revert -m 1 <merge-commit-hash>
-m 1 表示保留第一个父提交的版本（即保留当前分支的历史，丢弃被合并进来的那个分支的改动）。这是“撤销一个已经推送的 merge”最安全的做法。
5.3 rebase 误操作：从 reflog 中找 rebase 前的状态
Rebase 比 merge 更容易让人懵，因为它会重写提交历史。假设你执行了 git rebase develop，中途发现 rebase 出来的结果乱七八糟，想放弃：
bash复制git rebase --abort
这个命令会完全放弃当前 rebase，回到 rebase 开始之前的状态，和 merge --abort 类似。
但如果你已经完成 rebase，比如 rebase 成功后退出了，你才发现新历史不对，想回到 rebase 之前，办法依然是 reflog：
bash复制git reflog
# 找到类似 rebase: 之前那条记录，通常是 rebase finished 的那一行往下一条
git reset --hard <rebase之前的hash>
5.4 分支策略层面的保险：保护分支与本地备份
技术操作讲完了，讲点工程实践。出现这么多 merge/rebase 事故，根因往往不是命令不会用，而是分支太随意。我建议在团队协作中至少做到两条：
- 远程分支保护：在 GitLab / GitHub / Gitea 等平台上，把
main/master设置为保护分支，禁止直接 push，只允许通过 MR / PR 合并。这能杜绝最恶劣的“强制推送覆盖主分支”事故。 - 本地频繁打 tag：在重大合并前打个轻量 tag：
bash复制git tag backup-before-merge-2024-01-01
Tag 是一个永久的引用，不随 reflog 过期而消失。它比分支更轻量，也比记录一个哈希值更直观。
6. “Git 突然用不了了”：从环境配置到远程仓库连接排查
急救手册里怎么能少了环境排查？很多“误操作”其实不是命令的问题，而是 Git 本身没配好。下面按我见过的故障频率从高到低说。
6.1 “git 不是内部或外部命令”
Windows 上最常见的报错。执行 git 时提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。
原因通常有两个：一是 Git 根本没安装；二是安装了但没把 Git 的 cmd 目录加入 PATH。
解决办法：
- 到 Git 官网下载 Windows 版安装包，安装时选择“Git from the command line and also from 3rd-party software”。
- 确认安装目录下存在
cmd/git.exe，默认路径类似C:\Program Files\Git\cmd。 - 在系统环境变量 PATH 里加入这个目录，然后重新打开终端。
如果安装没问题但终端还是认不出，试试用完整路径运行 C:\Program Files\Git\cmd\git.exe，能跑就说明是 PATH 的问题。
6.2 fatal: not a git repository (or any of the parent directories)
这个报错的意思是当前目录不在任何 Git 仓库内。常见原因是你在一个不是仓库根目录的文件夹里执行了 Git 命令，或者 git status 时当前路径不属于任何已初始化的工作树。
排查方法：
bash复制pwd # 查看当前目录
ls -la # 查看是否有 .git 目录
如果在子目录里，Git 会自动向上查找父目录的 .git，所以正常情况是能用的。如果完全没有 .git，说明当前路径不是仓库。要么 cd 进正确的目录，要么用 git init 初始化。
6.3 clone、push、pull 频繁提示认证失败
远程仓库认证是最让人崩溃的环节之一。常见症状：
git clone https://...时反复弹账号密码框push时提示remote: HTTP Basic: Access denied- 某些 IDE 报
Login failed. Check API token or GitLab version之类的错误
解决思路分两步：
第一步：判断认证方式。 HTTPS 方式通常需要用户名 + 密码或 token，SSH 方式需要密钥对。你可以在仓库的远程地址上确认：
bash复制git remote -v
如果输出是 https:// 开头，就是用 HTTPS。如果要切换成 SSH：
bash复制git remote set-url origin git@github.com:用户名/仓库名.git
第二步：配置凭据缓存。 如果你确定账号密码没问题，但每次操作都要重新输入，那需要配置 credential helper。我推荐使用系统自带的凭据管理器：
bash复制git config --global credential.helper manager
Windows 上是 manager，macOS 上会自动使用 osxkeychain。
对于不希望每次输入密码的人，最省心的是配置 SSH 密钥：
bash复制ssh-keygen -t ed25519 -C "你的邮箱"
生成后将 ~/.ssh/id_ed25519.pub 内容添加到 Git 托管平台的 SSH Keys 中。之后测试：
bash复制ssh -T git@github.com
能收到欢迎信息，SSH 就通了。
6.4 关于 IDE 集成工具登录报错的排查思路
IDE 的 Git 插件（比如 VSCode 的 Git 插件）有时会提示类似 Login failed. Check API token or GitLab version 的信息。这通常不是 Git 本身的问题，而是 IDE 插件通过 API 访问平台时出了问题。
排查顺序是这样的：
- 确认你用的是哪种认证方式：如果是 GitLab，插件可能要求 Personal Access Token；如果是 GitHub，可能是 OAuth 或 PAT。
- 到平台设置页生成新的 token，确认勾选了
read_repository、write_repository等必要权限。 - 如果企业内部使用自签名证书或老版本 GitLab，可能还要检查 API 版本兼容性。最新的 IDE 插件可能不再兼容旧版 GitLab API，这时就要换回命令行操作，或者在插件设置里选择兼容模式。
这类问题我没有万能解法，因为每个 IDE 的插件实现差别很大，但通用思路是：先用命令行验证账号和权限，再回 IDE 里重新配置。 命令行能通，IDE 配置照抄就行。
6.5 让配置长期生效的两个小习惯
- 全局配置一次性设好：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --global init.defaultBranch main
user.name 和 user.email 会写入每一次提交的作者信息，不配清楚会导致提交显示成未知作者。此外还有 core.autocrlf，Windows 建议设置 true，macOS/Linux 建议设置 input，避免换行符导致的伪 diff。
- 别再让敏感信息出现在配置里：很多人会在命令行里直接写：
bash复制git clone https://用户名:密码@github.com/...
虽然能一次通过认证，但密码会出现在 shell 历史、进程列表甚至 IDE 的日志里。一旦被有心人翻到，账号就废了。正确做法是配好 credential helper，或者用 SSH。命令行里尽可能避免直接出现密码、token。
7. 安全红线：私有代码和密钥一旦提交，光删文件是不够的
最后用一个引以为戒的案例收尾。你有没有过这种经历：写了某个功能，突然发现代码里有一个写死的数据库密码或 API key，而且这段代码已经被 commit，甚至已经 push 到远程了？很多人的反应是“我把这把密钥从代码里删掉再提交一次就好了”。这个想法很危险。
7.1 为什么“删掉再提交”不够
Git 保存的是提交历史。即使你在最新的提交中删除了密钥文件，历史上的旧提交里仍然完整保留着它的内容。只要有人克隆过这个仓库、或者能看到提交历史，就能把旧提交翻出来，拿到密钥。而密钥一旦泄露，不管你怎么删，它都已经“出库”了——对方可能早就保存了。
所以，发现密钥提交后的第一件事：去平台撤销这个密钥，而不是只删代码。Git 操作只能减少泄露面，不能收回已经泄露的信息。
7.2 如何从 Git 历史中清除敏感文件
如果仓库还没被很多人克隆，而且你确定要清理历史，可以借助工具。
工具一：git filter-repo（推荐）
bash复制pip install git-filter-repo
# 克隆一个裸仓库副本
git clone --mirror 原仓库地址 temp-repo
cd temp-repo
# 删除历史中所有敏感的路径
git filter-repo --path 敏感目录 --invert-paths
# 强制推送所有分支
git push --force --mirror origin
工具二：BFG Repo-Cleaner
bash复制bfg --delete-files 密钥文件名
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push --force
这两个工具的作用类似，都是从所有提交历史中移除指定文件或路径，而不是只改最新提交。执行完后，还要让团队成员重新克隆仓库，因为旧的克隆副本里仍然带着历史。
7.3 从源头防止 .git 目录泄露
如果你负责部署网站或服务，还有一个极易被忽略的安全问题：站点目录下不小心带上了 .git 目录。
.git 目录里存放了整个仓库的历史、所有分支、所有提交对象。如果网站静态服务器允许直接访问 /.git/，任何访问者都有可能下载这个目录，从而完整还原你的源代码，甚至看到历史中的密钥、数据库配置等敏感信息。
热词里那些“git目录泄露如何下载”的搜索，就是这个场景的反面利用。我们要做的不是教人下载，而是防止自己成为受害者。
几个预防要点：
- 部署时不要整个文件夹复制。用
git archive导出干净的文件快照，而不是把.git一起拷上服务器：
bash复制git archive --format=zip -o release.zip main
- 服务器层禁止访问
.git目录。以 Nginx 为例，在配置中加入：
nginx复制location ~ /\.git {
deny all;
return 403;
}
- 定期检查线上站点：访问一下
你的域名/.git/config，如果返回的是文件内容而不是 403/404，说明泄露了，要立即处理。
7.4 gitignore：比任何急救都有效的防线
说到底，Git 误操作急救做得再好，也不如在源头拦住。.gitignore 文件值得你花时间认真维护：
gitignore复制# 密钥和配置
.env
*.pem
*.key
config/credentials.*
# 依赖和构建产物
node_modules/
dist/
build/
但注意，.gitignore 只对“尚未被跟踪的文件”生效。如果一个文件已经被 git add 或 git commit 过了，即使后来加进 .gitignore，Git 也会继续跟踪它。这时要先取消跟踪：
bash复制git rm --cached <文件名>
git commit -m "停止跟踪敏感文件"
这条命令会从暂存区和仓库中移除文件的跟踪，但保留本地文件。再配合 .gitignore，就能防止它再次被误提交。
这几年的经验让我的体会是：Git 的绝大多数“误操作”都不是无解的，真正无解的是你不了解自己在敲什么。遇到问题先停一下，跑一遍 git status 和 git reflog，搞清楚你当前处于哪个状态，再去查解决方案，你会发现很多网上的“急救命令”其实都是在做同一件事——把引用挪回你原本想待的位置。我自己的习惯是，任何一个我看不懂后果的命令，执行前都会随手记下当前分支的 HEAD，甚至直接建一个备份分支。这个动作只要花三秒钟，但能让你在恐慌时多一个可回退的锚点。希望这份手册能让你在 Git 翻车时多一点淡定，少一点“救命”的冲动。