VSCode无真正「一键回退版本」按钮，必须用git reset命令；右键“Reset Commit”仅支持--mixed模式且仅对最新提交生效，指定任意commit或选--soft/--hard须终端操作。
VSCode 里没有「一键回退版本」按钮，必须用 git reset 命令
VSCode 的 Git 集成不提供图形化 reset 入口，右键 commit 列表里所谓的 “Reset Commit” 仅对最新一次提交生效，且默认走 git reset --mixed HEAD~1；它不支持指定任意 commit、也不支持 --soft 或 --hard 模式选择。真要控制回退范围，终端是唯一可靠路径。
常见错误现象：点「Reset Commit」后发现文件没变、或改着改着代码突然没了——大概率是误以为它等价于 git reset --hard，实际它只清暂存区，工作区还在。
- VSCode 源代码管理面板右上角的「Undo Last Commit」按钮，底层就是
git reset --soft HEAD~1，但只在「刚提交、未 push、没切分支、没git commit --amend」时才亮起 - 想回退到任意历史 commit（比如
abc1234），必须打开集成终端，手动执行git reset命令 - 右键 commit 选「Revert Commit」不是 reset，而是生成新提交来抵消变更，历史记录仍保留
三种 reset 模式怎么选：看你想留什么、丢什么
核心区别就三点：HEAD 指针、暂存区（index）、工作区（working directory）是否被修改。别死记参数，盯住这三块状态就行。
-
git reset --soft HEAD~1：只动 HEAD，暂存区和工作区原封不动。适合改错提交信息、补漏文件，再提交一次 -
git reset --mixed HEAD~1（--mixed可省略）：动 HEAD + 清暂存区，工作区保留。所有已提交的改动退回为「已更改」状态，可重新git add筛选 -
git reset --hard HEAD~1：三者全重置。工作区文件立刻被覆盖为上上个提交的内容，未git add的临时修改永久丢失
性能/兼容性影响：三种模式底层都只是移动指针或覆盖文件，无网络或 IO 开销；但 --hard 在 Windows 上可能因文件锁导致失败，建议先关掉 VSCode 里正编辑的对应文件。
已 push 到远程的提交，千万别用 reset --hard
一旦 git push 成功，那条提交就进了团队共享历史。此时用 git reset --hard 再 git push --force-with-lease，会直接抹掉远程历史，协作者 git pull 时可能触发冲突、丢本地改动、甚至让 CI 流水线报错中断。
- 安全做法是
git revert HEAD：生成一条新提交，内容与目标提交完全相反，历史可追溯、协作无损 - VSCode 图形界面右键 commit →「Revert Commit」等效于此命令，但遇到合并提交（merge commit）会报错：
error: commit abc1234 is a merge but no -m option was provided - 此时必须切终端，加
-m 1参数：例如git revert -m 1 abc1234，表示以第一个父提交为基准反向操作
容易踩的坑：以为「Revert Commit」按钮能自动处理 merge，结果卡住；其实它根本不传 -m 参数，得手动补。
误操作后怎么抢救：reflog 是你的最后防线
git reset --hard 不是彻底删除，只要没运行 git gc，git reflog 通常还存着最近的操作快照。VSCode 不会自动刷新 reflog 视图，需手动点击源代码管理面板右上角刷新图标，或重启窗口。
- 执行
git reflog，找到目标状态对应的HEAD@{n}，比如HEAD@{2} - 运行
git reset --hard HEAD@{2}即可回退到那个时刻 - 如果 reset 后又做了新提交、再 reset、再提交……reflog 条目可能被覆盖，这时得翻
.git/logs/refs/heads/下的原始日志，或依赖本地备份
真正危险的不是 reset 本身，而是 reset 后继续开发、再 push —— 这会让 reflog 记录快速老化，抢救窗口期很短。
