用 git checkout head -- file.js 可恢复单个文件到最近一次提交，必须加 -- 防止误判为分支切换；若文件已暂存需先 git reset head file.js；git 2.23+ 推荐用更安全的 git restore。
Git 里怎么用 git checkout 回退单个文件
想恢复某个文件到上一次提交的状态，但又不想动其他文件，git checkout 是最直接的方式。它只改工作区，不碰暂存区和 HEAD，安全可控。
常见错误是输成 git checkout HEAD~1 -- file.js 却忘了加 --，结果 Git 把 HEAD~1 当作分支名报错：error: pathspec 'HEAD~1' did not match any file(s) known to git。
- 正确写法：
git checkout HEAD -- <code>src/utils.js（恢复到最近一次 commit） - 恢复到上上次：
git checkout HEAD~1 -- <code>src/utils.js - 必须加
--，否则 Git 可能误判为切换分支 - 如果文件已被暂存（staged），
git checkout不会覆盖暂存版本，得先git reset HEAD <code>src/utils.js
git restore 替代方案：更语义化但注意版本兼容性
git restore 是 Git 2.23+ 引入的新命令，目的就是替代容易混淆的 git checkout 文件恢复操作。它更直白，也更难误操作。
但如果你用的是旧版 Git（比如 macOS 自带的 2.20 或 Ubuntu 20.04 默认源里的版本），运行 git restore 会提示：git: 'restore' is not a git command。
- 恢复工作区：
git restore <code>src/utils.js - 恢复到指定 commit：
git restore -s HEAD~1 --worktree <code>src/utils.js - 只恢复暂存区（取消 add）：
git restore --staged <code>src/utils.js - VS Code 集成终端默认可能没更新 Git，建议用
git --version确认；Mac 用户推荐用 Homebrew 装最新版
整个项目回退到上一次提交：小心 git reset --hard 的不可逆性
如果所有文件都要回到上一次 commit，git reset --hard HEAD~1 最快。但它会丢弃当前所有未提交改动，且无法通过 git reflog 以外的方式找回。
典型翻车场景：在 feature 分支上执行了 git reset --hard，结果发现本地改的代码根本没 commit 过，也没推到远程——全没了。
- 执行前务必确认：
git status是否还有未保存的修改？git log --oneline -5看清楚 HEAD~1 到底是哪次提交 - 想保留当前修改但重置 HEAD 指针，用
git reset --soft HEAD~1（改完还能再 commit） - VS Code 左下角状态栏显示的分支名和 commit hash，就是
git reset的参照物，别光看文件树 - 远程分支不会被影响，但之后
git push会失败，需强制推送：git push --force-with-lease（仅限自己分支）
VS Code 内置 Git UI 能不能点几下就恢复？
可以，但有隐藏限制：它只显示「未暂存的更改」里的文件，且只能恢复到 HEAD，不能选 HEAD~1 或更早。
你右键一个已修改的文件 → “Discard Changes”，本质就是执行 git checkout HEAD -- <code>xxx。但如果这个文件已经被 git add 过，右键菜单里就只剩 “Restore Changes”（对应 git restore --staged），点完只是取消暂存，内容还在工作区。
- 想用图形界面恢复到任意历史提交，得装插件，比如 “GitLens”，它能在文件历史里点选某次 commit 后右键 “Revert File”
- VS Code 默认的 Source Control 视图不显示暂存区和工作区差异的层级关系，容易误判“已恢复”
- 编辑器里 Ctrl+Z 撤销的是编辑操作，不是 Git 操作，别指望它能回退到上一次 commit
Git 的“恢复”动作其实分三层：工作区、暂存区、HEAD 指针。很多人卡在以为点了“Discard”就万事大吉，结果发现文件还是黄的、还是有修改标记——那八成是它已经被 add 过了，得先处理暂存区。
