git checkout -- 仅对已跟踪且未暂存的文件生效，可恢复至暂存区或最后一次提交状态；对未跟踪文件无效，误用可能切换分支，安全替代是 git 2.23+ 的 git restore --worktree。
git checkout -- 是最直接的方式，但必须确认文件状态
它只对已跟踪（tracked）且处于“Changes not staged for commit”状态的文件生效。如果 git status 显示文件在 “Untracked files” 下，git checkout -- <file></file> 完全没反应——这不是命令错了，是它本来就不处理未跟踪文件。
常见错误现象：
- 输成
git checkout <file></file>（漏掉双横线），结果意外切换到同名分支，工作区被覆盖 - 对刚新建、还没
git add过的文件执行该命令，终端静默退出，误以为成功
正确做法：
- 先运行
git status，确认目标文件出现在 “Changes not staged for commit” 区域 - 确保写全
--，即git checkout -- <file></file> - 未跟踪文件直接删：
rm <file></file>或手动删除
git restore 更安全，但要注意 Git 版本和语义差异
git restore 是 Git 2.23+ 引入的替代方案，设计初衷就是解决 git checkout 一词多义带来的混淆。但它不是简单“换皮”，行为有关键区别：
- 默认只恢复工作区，不碰暂存区（
git checkout --实际上也如此，但语义不明确） - 若想同时清空暂存区 + 工作区，得显式加
--staged和--worktree参数 - Git 2.22 及更早版本不识别
git restore，会报错unknown command
示例：
git restore --worktree --staged README.md # 等价于 git reset HEAD README.md && git checkout -- README.md
如果你用的是公司统一的旧版 Git（比如 CentOS 自带的 1.8.x），别硬套 restore，老老实实用 checkout -- 更稳。
撤销前要分清：修改是否已 git add 过
这是最容易踩坑的认知盲区。git checkout -- <file></file> 恢复的目标，不是“最后一次 commit”，而是“最后一次 git add 或 commit”的快照。
- 如果改完没
add，它回退到上次commit的内容 - 如果改完又
git add了，它回退到add那一刻暂存区的内容（也就是你add前最后保存的版本）
也就是说，它永远不“跨区”操作。想一步回到 commit 状态？得先 git reset HEAD <file></file> 把暂存区撤掉，再 git checkout -- <file></file>。
别依赖 git checkout -- . 批量撤销，小心误伤
很多人图省事，用 git checkout -- . 撤销当前目录所有修改。这看似高效，但风险集中：
- 它对所有已跟踪文件生效，包括你其实想保留的调试日志、临时注释
- 如果当前目录下混着未跟踪文件（比如新生成的
config.local.json），它完全不管，但你可能误以为“全清干净了” - 没有预览机制，执行就不可逆（除非你记得刚改了什么）
更稳妥的做法是：
- 先
git status -s扫一眼，用M/MM标记快速定位真要丢的文件 - 针对性执行
git checkout -- file1.js file2.css - 真要批量，优先考虑
git restore配合-S（staged）和-W（worktree）参数，语义更可控
真正危险的不是命令本身，而是把“撤销”当成无脑回滚键——Git 的每个区域（工作区、暂存区、HEAD）都独立存着快照，搞不清边界，删掉的可能是你自己上周写的逻辑。
