git restore 更安全，因它专用于文件恢复，不切换分支；而 git checkout -- 在文件名与分支名相同时可能误切分支，且路径含空格时易解析错误。
用 git restore 最安全，它明确区分工作区和暂存区，不会误切分支或丢错文件。
为什么不用 git checkout --？
VSCode 1.56+ 默认调用 git restore，不是 git checkout --。后者在路径含空格、或文件名与分支名相同时，可能被 Git 解析为切换分支命令——比如你有个文件叫 main，执行 git checkout -- main 可能直接切到 main 分支，而不是还原文件。
-
git restore --worktree <file></file>：只还原工作区（VSCode 右键「Discard Changes」默认行为） -
git restore --staged --worktree <file></file>：同时清掉暂存区和工作区修改 -
git restore .：还原所有未暂存的文件（等效于 VSCode 的「Discard All Changes」）
git restore . 为什么有时没反应？
它只处理“未暂存的更改”，不碰已 git add 过的文件。如果你点了「Discard All Changes」但某些文件还在列表里，常见原因有：
- 文件被
.gitignore忽略但曾被跟踪过（即历史提交过）→ 仍会出现在 CHANGES 列表，可被还原 - 文件被
.gitignore忽略且从未被跟踪 → VSCode 根本不显示，git restore .也不会动它 - 权限变更（
chmod）或换行符差异（CRLF/LF）→ 默认不视为“修改”，除非设置了core.filemode=true或core.autocrlf=false - 子模块目录内的修改 →
git restore .不递归处理，需进子模块单独操作
想连暂存区一起清空，别只点「Discard All Changes」
VSCode 的「Discard All Changes」按钮默认只清工作区，不会碰暂存区。如果你已经 git add 过一堆文件，又想彻底回到上一次提交的状态，得先手动重置暂存区：
- 终端运行：
git reset --hard（清暂存区 + 工作区，慎用） - 或分步更可控：
git restore --staged .（清暂存区），再点 UI 的「Discard All Changes」（清工作区） - VSCode 源代码管理视图里，“STAGED CHANGES” 区域右键文件 → “Unstage” 也能逐个取消暂存
真正“一键清空全部”在 VSCode 里并不存在，必须明确自己要清哪一层——这是最容易被忽略的逻辑断层。
