误删文件后，90%的情况只需git checkout -- file即可恢复，前提是文件仅从工作区删除且未git add或git commit该删除操作；若已暂存删除，则需用git restore -s head -s -w file。
误删文件后，90% 的情况只需一条命令就能找回，不用翻历史、不需第三方工具——前提是还没 git add 或 git commit 那个“删除”操作。
git checkout -- file 是最常用也最容易出错的恢复方式
这是针对「文件仅从工作区删掉，Git 还记得它」的情况。执行 git status 后看到 deleted: src/main.ts，就属于这一类。
- 必须带双横线
--，否则 Git 会当成切换分支，报错error: pathspec 'src/main.ts' did not match any file(s) known to git - 如果当前不在默认分支（比如在
feature/login），HEAD仍有效；但若想从main恢复，得写git checkout main -- src/main.ts - Windows 路径含空格时，
file必须加引号：git checkout HEAD -- "docs/read me.md" - 这个命令会直接覆盖当前工作区的同名文件（如果存在），且不检查是否已有未提交修改——删之前有改过？那改的内容就丢了
git restore -s HEAD -S -W file 更安全，但只适用于 Git 2.23+
这是 git checkout -- 的语义替代品，专为“撤销工作区修改”设计，尤其适合你已经 git add 过被删文件的情况。
- 如果
git status显示deleted: xxx.js并标为staged（即已暂存删除动作），git restore才是真正清掉暂存+还原文件的组合操作 - 漏掉
--worktree（或-W）：文件依然消失，只取消了暂存 - 漏掉
--staged（或-S）：暂存区还留着“删除记录”，下次git commit会真删掉它 - 推荐写全参数：
git restore --source=HEAD --staged --worktree src/utils.ts，避免靠记忆缩写出错
文件已从历史中“消失”？用 git fsck --lost-found 找悬空提交
这种情况发生在你执行过 git reset --hard HEAD~1 或 git rebase，原提交不再被任何分支引用，但对象还没被 GC 清理。这不是恢复单个文件，而是先捞出可能含该文件的提交哈希。
- 运行
git fsck --lost-found，输出里会有类似lost-commit abc123...的行，这些是候选提交 - 对每个
abc123，手动检查：git ls-tree -r abc123 | grep your-file-name - 确认后执行：
git checkout abc123 -- path/to/your-file - 注意：
git fsck不保证一定能找到——如果对象已被git gc清理（你没手动执行，但 Git 可能在后台触发），这条路就断了
别碰 git reset --hard 和 git gc，除非你清楚后果
很多恢复失败，不是因为方法不对，而是后续操作把线索覆盖了。
- 看到
deleted:就立刻git add .？这等于把“删除”正式记入暂存区，再恢复就得用git restore，且多一步判断 - 手抖敲了
git commit -m "fix delete"？现在恢复要靠git reflog找上一个 HEAD，再git reset --soft回退，比原始场景多两步 - 运行
git gc或git prune？Git 会清理所有悬空对象，包括你还没来得及找的旧提交——2026 年 Git 默认不会自动 GC，但手动触发就是不可逆的
真正麻烦的从来不是“怎么恢复”，而是“删完之后你做了什么”。Git 的恢复能力很强，但它不会替你记住自己按下了哪些键。
