<p>git restore 更安全,因它专用于文件恢复,不切换分支;而 git checkout -- 在文件名与分支名相同时可能误切分支,且路径含空格时易解析错误。</p>

用 git restore 最安全,它明确区分工作区和暂存区,不会误切分支或丢错文件。
为什么不用 git checkout --?
VSCode 1.56+ 默认调用 git restore,不是 git checkout --。后者在路径含空格、或文件名与分支名相同时,可能被 Git 解析为切换分支命令——比如你有个文件叫 main,执行 git checkout -- main 可能直接切到 main 分支,而不是还原文件。
-
git restore --worktree <file>:只还原工作区(VSCode 右键「Discard Changes」默认行为) -
git restore --staged --worktree <file>:同时清掉暂存区和工作区修改 -
git restore .:还原所有未暂存的文件(等效于 VSCode 的「Discard All Changes」)
git restore . 为什么有时没反应?
它只处理“未暂存的更改”,不碰已 git add 过的文件。如果你点了「Discard All Changes」但某些文件还在列表里,常见原因有:
GInstall OneClick — 一键安装 GitHub 项目:规划、克隆、安装 Node 依赖、运行开发脚本。适用于想要获取 GitHubNode.js 项目的用户。
- 文件被
.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 里并不存在,必须明确自己要清哪一层——这是最容易被忽略的逻辑断层。

















