汤一白君手滑删了分支、提交记录被 reset 冲掉、merge 到一半想反悔、push 的时候发现证书报错、明明在项目目录里却提示 fatal: not a git repository……这些场景几乎每个用过 Git 的人都经历过。Git 最"反直觉"的地方在于：它默认对误操作很宽容，只要你没有主动清理垃圾对象，绝大多数被"删掉"的提交和文件都能找回来。这份 Git 误操作急救手册，就是从这些常见翻车现场入手，讲清楚恢复原理和具体命令，也把 clone、push、证书、凭据这类看似不是误操作、实际同样耽误事的坑一起收拾了。无论你是刚开始接触 git add .、git commit 的新手，还是整天跟分支和 rebase 打交道的老手，都能在对应的场景里找到可落地的恢复方案。
1. 误操作急救的第一原则：先停下，别继续执行命令
1.1 为什么要先停：.git 目录本身就相当于一个"回收站"
碰到误操作，大部分人的第一反应是赶紧执行几条命令"把状态改回去"。但 Git 和普通文件管理器不同，它的每次操作并不是直接物理删除，而是先把旧的提交对象、引用关系保留在 .git/objects 里，再生成新的提交对象。换句话说，Git 的"删除"大多只是把一个指针挪走，数据本身还躺在对象库里。
这就像你把桌面上的文件拖进了回收站，只要没清空回收站，文件就还在。Git 里的"回收站"就是对象库，而 git gc、git prune 这类命令就相当于"清空回收站"。所以误操作后的第一原则是：停下手里的操作，不要再继续执行会改写 HEAD、移动分支或触发垃圾回收的命令。继续操作越多，对象被覆盖和回收的概率越大。
1.2 急救前的三分钟：快速确认当前状态
先别慌，打开终端，依次执行下面四个命令，把现场情况摸清楚：
bash复制git status
git log --oneline --graph --all -20
git reflog -20
git stash list
这四个命令分别告诉你四件事：当前工作区和暂存区处于什么状态、分支历史上还能看到哪些提交、HEAD 指针最近移动过的轨迹、以及有没有被临时保存的 stash 记录。
其中 git reflog -20 是最重要的急救入口。它记录了 HEAD 指针每一次移动的轨迹，包括 commit、reset、checkout、merge、rebase 等操作，哪怕是"已经删掉的分支"，只要它曾经的 HEAD 移动记录还在，就能找到对应的提交哈希。确认这几个状态后，再决定要不要执行恢复命令。
1.3 提交、暂存、工作区的概念边界：判断"我到底丢在哪一层"
恢复之前先搞清楚数据丢在哪一层，才能选对命令。Git 的数据状态分三层：
- 工作区：你编辑器里正在修改的文件，还没有执行
git add。 - 暂存区：执行
git add后、git commit前的中间状态。 - 本地仓库：执行
git commit后的提交记录，以及分支引用。
这三层的数据性质完全不同。工作区里的未跟踪文件一旦被 git clean -fd 删掉，Git 本身没有任何记录，恢复难度极高；本地仓库里的提交被 reset 掉，则大概率能通过 reflog 找回来。急救时先问自己：这个文件我 commit 过吗？我 add 过吗？如果 commit 过，恭喜，基本都能救回来；如果只是 add 过，工作区版本没了，但暂存区快照还在；如果既没 add 也没 commit，那就只能靠编辑器本地历史或文件恢复工具碰运气了。
提示：误操作后的第一件事绝对不是"凭记忆执行 git reset --hard"，而是先把当前分支名和 HEAD 哈希记下来。最稳妥的做法是开一个文本文件，或者直接复制终端里
git log的哈希值，作为后续恢复的锚点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 代码丢了怎么找：reflog、fsck 与 reset/restore 的实战用法
2.1 git reflog：Git 的后悔药，记录每一次头指针移动
git reflog 是 Git 急救里出场率最高的命令。它记录的是 HEAD 指针过去的每一次指向变化，默认保留 90 天。举个例子，你执行了 git reset --hard HEAD~3，原本最顶端的提交从分支引用上消失了，但 reflog 里依然能看到：
bash复制$ git reflog
a1b2c3d HEAD@{0}: reset: moving to HEAD~3
e4f5a6b HEAD@{1}: commit: feat: 完成订单模块
c7d8e9f HEAD@{2}: commit: fix: 修复登录超时
HEAD@{1} 对应的就是 reset 之前你所在的提交。要恢复，只需要：
bash复制git reset --hard HEAD@{1}
如果误操作的是删除分支，比如执行了 git branch -D feature/login，reflog 里同样能看到这个分支最后一次指向的提交哈希。执行：
bash复制git checkout -b feature/login a1b2c3d
就能把分支重新建回来。为什么能恢复？因为 git branch -D 只是删掉了 refs/heads/feature/login 这个引用文件，提交对象本身还在对象库里，通过 reflog 找到哈希后重新关联即可。
2.2 reflog 也没记录时，用 git fsck --lost-found 捞回悬空对象
有时候 reflog 也帮不上忙，比如误操作发生在刚 clone 的仓库里，或者某个提交从未被任何分支引用过，reflog 里根本没有记录。这时候要用 git fsck 扫描对象库里的"悬空对象"：
bash复制git fsck --lost-found
执行后你会看到类似这样的输出：
bash复制dangling commit a1b2c3d1234567890abcdef
dangling blob 4d5e6f7g8h9i0j1k2l3m4n5o
dangling commit 就是"没有被任何分支和标签引用、但对象库还保存着的提交"。找到之后，用 git show 查看具体内容确认是不是你要找的：
bash复制git show a1b2c3d1234567890abcdef --stat
确认无误后，用 git cherry-pick 或者新建分支把它恢复出来：
bash复制git branch recover-missing-branch a1b2c3d1234567890abcdef
git fsck --lost-found 是清理场景之外最可靠的兜底手段。不过它有一个前提：对象还没有被 git gc --prune=now 这类命令彻底清掉。所以再次强调，误操作后不要急着执行任何清理命令。
2.3 reset、restore、checkout 三兄弟的真正分工
这三个命令是 Git 新手最容易搞混的"三兄弟"。很多人以为它们都能撤销改动，结果用错命令反而扩大了问题。它们的核心区别，我用一张表来说明：
| 命令 | 默认作用对象 | 是否移动分支指针 | 典型场景 |
|---|---|---|---|
git restore <file> |
工作区 | 不移动 | 放弃某个文件的未提交修改 |
git restore --staged <file> |
暂存区 | 不移动 | 取消已 add 的文件 |
git reset --soft <commit> |
分支指针 | 移动 | 撤销 commit，保留改动到暂存区 |
git reset --mixed <commit> |
分支指针+暂存区 | 移动 | 撤销 commit，保留改动到工作区 |
git reset --hard <commit> |
分支指针+暂存区+工作区 | 移动 | 彻底回到某个 commit |
git checkout <branch> |
分支 | 切换 | 切换分支 |
git checkout -- <file> |
工作区 | 不移动 | 用暂存区版本覆盖工作区 |
急救时最需要记住的是：git reset --hard 是破坏性最强的操作，它会同时覆盖工作区和暂存区。如果你只是不小心改了某个文件想还原，用 git restore <file> 就够了；如果你只是想把某个文件从暂存区撤回来，用 git restore --staged <file>。只有当你确实想"整个分支状态回退"时，才考虑 git reset --hard，且回退前一定先从 reflog 里确认目标哈希。
2.4 git clean -fd 删了未跟踪文件，还能不能救
git clean -fd 删的是未跟踪文件，这类文件从来没有进入过 Git 的对象库，所以 Git 内部没有任何恢复机制。遇到这种误操作，只能依靠 Git 之外的兜底手段：
- IDE 本地历史：IDEA、VS Code 等编辑器通常会保留文件本地历史记录，只要文件还在项目目录里打开过，可以通过"Local History / Timeline"恢复。
- 编辑器缓存：有些编辑器会保留临时备份文件，查找
.swp、~后缀或.idea的 backups 目录。 - 文件系统工具：如果是刚删除、且文件系统是机械硬盘或支持快照的存储，趁数据未被覆盖前使用文件恢复工具，成功率尚可；SSD 上就非常看运气了。
给一个切实建议：对于重要的工作区未跟踪文件，平时养成用了就 git add 的习惯，或者至少放进一个已跟踪目录下的子目录里。如果你担心 git clean 会把误删未跟踪文件，写命令时可以加 -n 先做一次"演练打印"，确认要删的文件列表再执行：
bash复制git clean -nfd
git clean -fd
3. 提交记录翻车：amend、merge、rebase 和强推的救援方案
3.1 git commit --amend 执行完后想反悔怎么办
git commit --amend 会把当前提交和暂存区的内容合并成一条新提交，同时生成新的提交哈希。误操作场景通常有两种：一是手滑把不想提交的文件一起 amend 进去了，二是 amend 之后发现提交信息写错了想撤回。
第一种情况，要找回 amend 之前的原始提交，reflog 依然有效。在 git reflog 里，amend 前的提交会以 commit: ... 的形式保留在操作记录中：
bash复制$ git reflog
a1b2c3d HEAD@{0}: commit (amend): fix: 修正提交信息
e4f5a6b HEAD@{1}: commit: fix: 原始提交
如果只想撤销 amend、回到原始提交并保留工作区改动，可以执行：
bash复制git reset --soft HEAD@{1}
这样会把分支指针移到 amend 之前的提交，暂存区保留着 amend 后产生的差异，你就能重新整理提交内容。
第二种情况，如果只是提交信息写错，但提交内容没问题，直接再执行一次：
bash复制git commit --amend -m "正确的新提交信息"
重复 amend 也没有关系，因为 reflog 永远保留着上一个版本。
3.2 merge 冲突处理到一半想全盘放弃
merge 冲突是日常频率最高的翻车现场。处理完几个冲突文件，结果发现这个分支思路不对，想全部放弃、回到 merge 之前的状态。此时最重要的概念是：git merge 操作会自动记录一个 ORIG_HEAD，指向 merge 之前你所在的分支位置。
放弃 merge 的标准命令是：
bash复制git merge --abort
这个命令会自动恢复到 merge 操作之前的 HEAD 状态，并清理工作区改动。如果你已经手动解决了一部分冲突文件、甚至已经 add 过，--abort 也能正常回退，因为它读取的是 merge 开始时的原始状态。
如果 git merge --abort 因为某些原因失败（比如中途有其他操作污染了状态），还有一个兜底方案：
bash复制git reset --hard ORIG_HEAD
ORIG_HEAD 是一个指针，保留着 merge 之前的分支头。直接用 reset 回到这个位置，效果等同。不过要注意，ORIG_HEAD 是一把双刃剑：如果 merge 之后你又执行了别的重操作，它可能已经被覆盖，所以越早使用越可靠。
3.3 rebase 中断或 rebase 错分支的撤销
rebase 出问题的场景比 merge 更复杂，因为 rebase 会把提交历史整个重放一遍。最常见的错误是：应该在 A 分支上 rebase，结果在 B 分支上执行了 git rebase，导致 B 分支的提交历史全部被重写。
如果 rebase 正处在冲突中断状态，想完全放弃，最简单的是：
bash复制git rebase --abort
执行后 Git 会自动恢复到 rebase 前的状态，工作区和暂存区一并还原。
如果你已经完成了 rebase，事后才发现 rebase 错了分支，情况麻烦一点，但也不用绝望。reflog 里保留着 rebase 之前 HEAD 的位置，通常就在 reflog 的上方几条记录里。先查看：
bash复制git reflog
找到 rebase (start) 之前的那条 HEAD@{n} 记录，然后执行：
bash复制git reset --hard HEAD@{n}
如果你不想丢掉 rebase 后任何零散的补救改动，可以改用 git reset --soft 或先把当前状态 commit 到临时分支，再从 reflog 恢复。另外，rebase 操作会有一个 ORIG_HEAD 记录，但 rebase 整个过程可能移动很多次 HEAD，所以 reflog 比 ORIG_HEAD 更可靠。
3.4 push --force 覆盖远程分支后的恢复
强推是误操作里最"致命"的一种：你本地分支落后于远程，直接 git push --force 把远程分支覆盖了，但同事刚刚推上去的提交就这么凭空消失。好消息是，本地 reflog 里通常还有远程分支之前指向的提交记录。
先确认本地能否看到那个"消失"的提交：
bash复制git reflog
git log --all --oneline --graph -20
如果本地有对应的对象，直接新建分支指向它还原：
bash复制git branch recover-remote-branch <lost-commit-hash>
git push origin recover-remote-branch
然后通过 Merge Request 或直接推送恢复远程分支。如果本地也找不到这个对象，那就得去找其他同事的本地仓库，让持有该提交的人推送一次。这个教训的通用版本是：能用 --force-with-lease 就不要用 --force。
bash复制git push --force-with-lease
--force-with-lease 会在推送前检查远程分支是否还是你上次 fetch 时的状态。如果过程中有其他人推送了新提交，这个命令会直接拒绝覆盖，相当于给强推加了一道安全闸门。
4. 环境与连接报错：clone、push、pull 中那些"假误操作"
4.1 fatal: not a git repository：为什么仓库突然"找不到"了
fatal: not a git repository (or any of the parent directories): .git 这个报错，几乎所有人都在某个时刻见过。表面上看像是仓库坏了，其实大多数情况只是你在不该执行 Git 命令的目录里执行了命令。
排查路径很简单：
- 先执行
pwd确认当前目录是你以为的那个目录。如果你在子目录里，Git 会向上查找.git目录，只有所有父级目录都没有.git时才会报这个错。 - 检查当前目录下是否有
.git文件或.git目录：ls -la。 - 子模块场景下，
.git往往是一个文件而不是目录，内容指向主仓库的modules目录，如果主仓库路径变化，子模块也可能报出这个错，这时需要检查.git文件内容里的路径是否有效。 - 环境变量
GIT_DIR被误设置时也会导致 Git 找不到仓库。执行echo $GIT_DIR检查，必要时unset GIT_DIR。
绝大多数情况下，这个报错不是仓库数据损坏，而是"你在错误的目录里执行了命令"。但也有一种例外：你确实在仓库目录里，但 .git 目录被误删或改名了。这种情况如果改动没提交，恢复就非常困难，所以日常高频提交的价值再次体现出来。
4.2 git 不是内部或外部命令：安装与环境变量问题
git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称 这类报错，本质上是系统找不到 git 可执行文件。常见场景是在 Windows 的命令提示符或 PowerShell 里执行 git，但安装 Git 时没有把 git 加入 PATH。
解决方式有两种：
- 重新安装并勾选 PATH 选项：运行 Git 安装包，在安装到 "Adjusting your PATH environment" 这一步时，选择 "Git from the command line and also from 3rd-party software"。这样 Git 会把
cmd、git.exe所在目录加入系统 PATH。 - 手动添加环境变量：右键"此电脑" → 属性 → 高级系统设置 → 环境变量，在用户变量或系统变量里找到
Path，把 Git 安装目录下的cmd目录（例如D:\Git\cmd）添加进去，保存后重新打开终端。
如果你在用 Git Bash，则一般不需要额外配置；但如果在 VS Code 的终端里报这个错，通常是因为 VS Code 启动时继承的环境变量没有刷新，重启 VS Code 或重新打开终端即可。
4.3 unable to access / error setting certificate file：SSL 证书问题
unable to access 'https://...': error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt 这类报错，本质是 Git 在发起 HTTPS 请求时找不到可用的 CA 证书包。常见于 Windows 下 Git 安装路径迁移、证书文件缺失，或者系统代理环境导致证书路径被改写。
先确认 Git 当前使用的证书路径：
bash复制git config --global --list | grep ssl
git config --global http.sslCAInfo
如果路径指向一个不存在的文件，就需要修复。两个方向：
- 重新指定正确的证书文件：Git 安装目录下一般自带
mingw64/etc/ssl/certs/ca-bundle.crt，找到后执行：
bash复制git config --global http.sslCAInfo "D:/Git/mingw64/etc/ssl/certs/ca-bundle.crt"
- 临时关闭证书校验（不推荐长期使用）：
bash复制git -c http.sslVerify=false clone https://...
sslVerify=false 只能用来临时绕过问题，比如调试网络环境或内网自签名证书的场景，千万不要把它写进全局配置里，否则等于把所有 HTTPS 仓库的传输安全都干掉了，抓包工具可以直接读到你的账号口令。
如果报错还伴随着代理信息，比如公司内网需要走代理才能访问外网仓库，检查一下：
bash复制git config --global --get http.proxy
git config --global --get https.proxy
代理配置错误同样会引发 unable to access。确认代理地址、端口是否真实可用，不需要代理时用 git config --global --unset http.proxy 清掉。
4.4 login failed / auth token 问题：凭据配置要梳理
login failed. check api token or gitlab version. log in via git if the version... 这类报错，常见于 GitLab 平台和 IDE 集成工具配合时。本质是 Git 客户端发送的认证凭据和 GitLab 端期望的凭据不匹配。
排查思路分三步：
- 确认 GitLab 版本是否过旧。部分老版本 GitLab 的 API 认证方式和新版 Git 的 credential manager 不兼容，报错信息里甚至会提示你使用
git命令行方式登录。 - 检查已存的凭据。Windows 上可以通过"控制面板 → 用户账户 → 凭据管理器 → Windows 凭据"查看有没有旧的 Git 凭据，删掉旧记录后重新执行推送。
- 使用 Personal Access Token。在 GitLab 账号设置里生成一个带
read_repository、write_repository权限的 token，把它作为密码输入。
免密配置方面，还有一套更长期稳定的做法。最推荐的是配置 SSH key，在 GitLab 的 SSH Keys 里添加公钥后，用 SSH 协议的 clone 地址操作，全程无需输入密码。其次是 credential.helper：
bash复制git config --global credential.helper store
store 模式会把凭据明文存在 .git-credentials 文件里，适合个人开发机；如果你在公司共享机器上，建议用 manager 模式（Windows 的 Git Credential Manager），它把凭据加密存放在系统凭据库中，更安全一些。
4.5 别再让 .git 目录泄露：安全遗漏也算误操作
"git目录泄露如何下载"这个话题在安全圈很常见，但作为日常使用 Git 的人，更应该关注的是"如何防止自己的项目 .git 目录被公开访问"。如果你的项目被打包部署到 Web 服务器时，不小心把 .git 目录一起发布了，就等于把完整的提交历史、分支、甚至可能存在的内部敏感配置全部暴露了。
这不是一个"下载别人 .git"的教程场景，而是给开发者的安全红线：部署项目时，先检查发布包里是否包含 .git 目录。如果用的打包工具，可以在配置里显式排除：
.gitignore文件只在 Git 仓库层面生效，不适用于 Web 服务器目录访问控制。- 在 Nginx 配置里增加一条拒绝规则，禁止访问以
.git开头的路径：
nginx复制location ~ ^/\.git {
deny all;
}
另外，不要在前端项目源码里把远程仓库地址硬编码成带账号密码的形式，也不要把 token 写到 .git/config 里再推送到公共平台。误操作删除远不如误操作泄露危害大，这部分的安全意识也和急救手册强相关。
5. 防误操作设计：提交规范、免密配置与日常防呆习惯
5.1 提交规范如何降低误操作成本
很多人觉得提交规范只是"团队审美问题"，但站在误操作急救的角度，规范的提交信息能显著降低恢复成本。当 reflog 里出现十几条 commit: 临时提交 时，你很难判断该恢复到哪一条；但如果提交信息是 fix: 修复登录态过期问题 这种明确格式，恢复时一眼就能锁定目标。
目前使用最广的是 Conventional Commits 规范：
text复制<type>(<scope>): <subject>
常见 type 有：
feat：新功能fix：修复问题docs：文档变更style：格式调整，不影响逻辑refactor：重构test：补测试
如果你习惯用中文提交，也可以采用类似结构，比如 修复：登录接口超时、功能：增加导出按钮。重点不是用哪套规范，而是保持一致性。一个额外好处是，规范的提交信息可以直接被自动化版本工具识别，生成 changelog 也不需要手工整理。
5.2 免密配置：clone、push 不再反复输入账号密码
免密配置看似和工作效率相关，实际上也是防误操作的组成部分。反复输入密码容易触发人对命令的"敷衍心理"，比如图省事直接复制一串带 token 的 URL，反而更容易把凭据泄漏到日志里。两条主流免密路线：
SSH 免密：
bash复制ssh-keygen -t ed25519 -C "your_email@example.com"
生成后把公钥（默认在 ~/.ssh/id_ed25519.pub）添加到 GitLab/GitHub 的 SSH Keys 设置里。然后 clone 时使用 SSH 地址：
bash复制git clone git@github.com:user/repo.git
HTTPS 凭据助手：
bash复制git config --global credential.helper manager
这样第一次输入一次密码或 token 后，系统会缓存凭据，之后不再询问。如果你在 CI/CD 环境里，更推荐用环境变量注入 token，避免把凭据写进可公开的脚本文件。
5.3 常用防呆技巧：保护分支、stash、graph 可视化
防误操作不等于"少用命令"，而是给关键操作加点护栏。我自己的习惯，有三件事非常值得坚持：
第一，给重要分支开启保护。在 GitLab/GitHub 的项目设置里，把 main、master、release 分支设置为"禁止直接推送"，只有通过 Merge Request 才能合入。这样即使你不小心在这个分支上执行了破坏性命令，影响也会被平台的保护机制拦截或提示。
第二，临时切换分支前先 git stash，而不是带着一堆未提交改动直接 checkout。如果你在一个分支上改了文件，切到另一个分支时产生了冲突，Git 会要求你先处理，有些新手在这个流程里执行了 git checkout -- .，导致改动全部丢失。正确做法是：
bash复制git stash push -m "wip: 登录模块调整"
git checkout another-branch
git stash pop
git stash 的好处是，它把当前工作区的改动做成一个提交对象保存在 stash 栈里，之后随时可以通过 git stash list 和 git stash apply 找回来，比直接丢弃安全得多。
第三，用可视化工具查看分叉结构。命令行固然强大，但 git log --graph 在分支很多的情况下很难一眼看清整体。VS Code 的 Git Graph 插件、Git Extensions、小乌龟（TortoiseGit）都能提供图形化的分支视图。可视化并不丢人，关键时刻能让你及时发现"我是不是在错误的分支上执行了 merge/rebase"。
5.4 不可见的救星：给 .git 目录做一次离线备份
有时候误操作已经到了"对象被 gc 清掉"的极端程度，reflog 和 fsck 都救不回来。这种时候，如果有一个 .git 目录的历史备份，就能把分支引用和对象库整体恢复回去。
一个非常朴素的办法：在做大的结构变更（比如大规模 rebase、删除分支、清理历史）之前，直接把 .git 目录打一个压缩包：
bash复制tar -czf git-backup-YYYYMMDD.tar.gz .git
这个备份只针对 .git 目录，不包含工作区文件，所以体积通常不大。恢复时把当前仓库的 .git 目录替换成备份包里的内容，再执行 git status 确认分支和工作区状态。
我自己经历过一次因为误执行 git gc --prune=now 导致大量悬空对象被清掉的场景，当时唯一能救我的就是前一天留下的 .git 备份。所以现在我对 .git 备份的态度是：不频繁做，但重要节点必须做。
6. 写在后面：一次真实抢救复盘与我的固定应急包
6.1 昨天我差点删掉整个 feature 分支
上个月，我在一个功能分支上连续开发了两天，提交了大概十几次。因为需求有变，我打算把分支重置到远程的 origin/main 上重新来。当时我脑子一热，执行了：
bash复制git reset --hard origin/main
执行完的瞬间我就意识到不对，工作区里的所有改动都没了，本地那十几条提交也从分支上消失了。我愣了几秒，然后想起第一条原则：不要再操作。我打开另一个终端，执行 git reflog，果然找到了 reset 前的记录。几分钟后，我用 git reset --hard HEAD@{1} 把整个分支恢复到 reset 之前的状态，改动一条没丢。
那次之后我做了一个决定：把急救用到的高频命令整理成一个固定的"应急包"，每次遇到误操作就按顺序执行：
bash复制# 1. 先定位
git status
git reflog -30
# 2. 找到目标哈希后，再决定恢复方式
# 恢复分支和提交，不碰工作区
git reset --soft <hash>
# 恢复分支并保留暂存区
git reset --mixed <hash>
# 彻底恢复（确认清楚再用）
# git reset --hard <hash>
# 3. 找不到 reflog 就查悬空对象
git fsck --lost-found
6.2 我的急救"应急包"：一组固定命令
这个应急包里，真正每天都会用到的可能只有前两条，但只要出现误操作，它们就是第一道防线。还有几个和我个人习惯强绑定的建议：
- 我几乎不用
git clean -fd，必须用的时候一定先-n打印预览。 - 我很少用
git push --force，强制推送永远用--force-with-lease兜底。 - 我在每次重要操作前，都会先
git reflog看一眼当前 HEAD 的位置，相当于"操作前拍照"。 - 我习惯把
git stash list当作"临时保险柜"，切换分支或实验性改动前都会 stash 而不是丢弃。
最后想对看到这里的读者说一句：Git 误操作急救的本质不是"记住更多命令"，而是理解 Git 对象模型不会轻易丢数据。只要你不慌、不乱跑清理命令、懂得用 reflog 和 fsck 找对象，绝大多数"删库"级别的失误都能挽回。希望你用不上这份手册，但一旦用上了，希望它是你的最后一根救命稻草。