<p>git checkout HEAD -- 可恢复已删但未提交的文件，本质是将HEAD中副本写回工作目录；git restore适用于暂存后删除的文件，需用--source=HEAD --staged --worktree参数组合。</p>
git checkout 恢复已删但未提交的文件
文件刚删、还没 git add 或 git commit，Git 仓库里还存着上一次提交的版本，这时候恢复最简单。本质是把暂存区（或 HEAD）里的副本重新写回工作目录。
常见错误现象：git status 显示 “deleted: xxx.js”，但 git log 能查到它之前存在；直接手动新建同名文件再 git add 会丢掉原内容，不是恢复，是覆盖。
- 用
git checkout HEAD -- <file></file>（注意双横线），比如git checkout HEAD -- src/utils.ts - 如果当前分支不是默认分支，
HEAD可换成具体分支名，如git checkout main -- package.json - 不加
--容易被 Git 当成切换分支命令，报错error: pathspec 'xxx' did not match any file(s) known to git - Windows 下路径含空格时，
<file></file>建议加引号，如git checkout HEAD -- "docs/read me.md"
git restore 恢复暂存后又删掉的文件（Git 2.23+）
git restore 是 Git 2.23 引入的更语义化的命令，专为“撤销工作区修改”设计，比 git checkout 更安全、意图更明确。适用于删了文件且已经 git add 过（即暂存区也有记录）的情况。
使用场景：你执行了 git add deleted-file.txt，然后又 rm deleted-file.txt，此时 git status 显示 “deleted: deleted-file.txt” 并标记为 staged。这时 git checkout HEAD -- 仍有效，但 git restore 更精准。
-
git restore --source=HEAD --staged --worktree <file></file>：同时清暂存 + 恢复工作区（最常用） - 简写为
git restore -s HEAD -S -W <file></file>，但建议写全参数，避免记混 - 漏掉
--worktree只会取消暂存，文件依然消失；漏掉--staged则暂存区残留删除记录，下次git commit会真删掉它 - 老版本 Git（git restore，强行运行会提示
unknown subcommand
git fsck 找回已提交但被强制 reset 删除的文件
执行过 git reset --hard HEAD~1 或 git rebase 后，原提交虽不在分支引用上，但对象可能还在 Git 对象库中，没被 GC 清理。这是唯一能找回“已提交但分支指针移走”的文件内容的方式。
关键点：不是恢复整个文件，而是先定位“丢失提交”的 hash，再从那个提交里取文件。Git 不会自动告诉你哪个提交含你要的文件，得靠 git fsck 扫描悬空对象，再逐个检查。
- 先运行
git fsck --lost-found，输出类似lost-commit abc123...的行，这些是可能的候选提交 - 对每个疑似 hash，用
git show abc123:path/to/file.txt查看内容是否匹配（注意路径是相对于仓库根目录） - 确认后，用
git show abc123:path/to/file.txt > file.txt重定向保存 - GC 通常 14 天后才清理悬空对象，但手动执行过
git gc就可能永久丢失，别等太久 -
git reflog更快——它记录 HEAD 移动历史，git reflog输出里找带 “commit: xxx” 的行，对应 hash 直接git checkout <hash> -- file.txt
rm -rf 后连 .git 都没了？基本没救
如果整个项目目录被 rm -rf，包括 .git 文件夹，那本地 Git 仓库彻底消失。此时所有未推送到远程的历史、分支、暂存信息全部丢失，只剩你电脑里有没有备份、编辑器有没有本地历史、IDE 是否启用了本地快照这些外部因素。
这不是 Git 能解决的问题，而是数据备份层面的失效。很多人误以为 “Git 存了所有版本”，其实它只存于 .git 目录内，删了就没了。
- 远程仓库（如 GitHub）只有你显式
git push过的分支和提交才存在；没 push 的本地提交，远程一概不知 - 部分 IDE（如 VS Code 的 Local History 插件、WebStorm 的本地历史）可能缓存过文件快照，但非 Git 行为，不能依赖
- 系统级回收站（macOS 废纸篓 / Windows 回收站）有时能捡回
.git，但概率低，且需立刻操作——延迟越久，磁盘覆写风险越高 - 真正可靠的方案只有定期
git push+ 外部备份（如 Time Machine、rsync 到 NAS），而不是事后指望 Git 自救
