VSCode终端执行git rebase -i需先设core.editor为code --wait，运行git rebase -i HEAD~n后修改todo列表中pick为s/e，关闭标签页触发执行；误操作可用git reset --hard ORIG_HEAD回退。
VSCode 内置 Git 面板能覆盖 90% 的日常操作，但真正卡住你的，往往是那 10% 的高级场景：比如想重写最近三次提交、把某次提交“摘出来”用到当前分支、或者临时藏起一堆未完成修改去紧急修 bug——这些没法点点鼠标搞定，必须调用 Git 命令，而且得在 VSCode 终端里安全执行。
怎么在 VSCode 终端里正确运行 git rebase -i
这个命令不是用来“美化历史”的装饰品，而是解决多人协作中提交混乱的核心工具。比如你本地有 5 次提交，其中第 2 次改错了 API 地址，第 4 次漏了测试，你想把它们合并进第 5 次一起修正，而不是留一堆“fix typo”“add test”碎片。
- 先确保终端已定位到项目根目录（
git status能正常输出） - 运行
git rebase -i HEAD~5，不要直接写HEAD~3——VSCode 终端默认不支持交互式编辑器弹出，会卡在 vim 界面；必须提前设置好编辑器：git config --global core.editor "code --wait" - 命令执行后会自动打开一个临时文件，把要 squash 或 edit 的提交前的
pick改成s或e，保存并关闭；VSCode 会等你改完再继续 - 如果选了
e，改完代码后必须运行git add . && git rebase --continue，漏掉--continue会导致分支处于REBASEING状态，后续所有操作都会被拒绝
git stash 不只是“暂存”，关键在怎么精准恢复
很多人用 git stash 就是图个省事，结果 stash 列表堆到 10 条，根本分不清哪条对应哪个功能分支。更糟的是，git stash pop 默认恢复最新一条，但如果你刚切到另一个分支，它可能把 A 分支的改动错 applied 到 B 分支上。
- 每次 stash 都加描述：
git stash push -m "wip: user-profile-api-refactor"，这样git stash list一眼能识别 - 恢复指定 stash：
git stash pop stash@{2}，而不是无脑pop - 只应用某次 stash 的部分文件：
git stash show -p stash@{0} | git apply，再手动git add想保留的改动 - 误 pop 后想撤回？只要还没 commit，
git reset --hard ORIG_HEAD可秒退，这是 VSCode 图形界面完全不暴露的隐藏状态指针
为什么 git cherry-pick 总报错 “fatal: bad revision”
这个错误几乎都源于两个低级但高频的问题：一是复制了带空格或换行的 commit hash，二是没注意当前分支是否已 fetch 远程最新记录。
- commit hash 必须完整复制（40 位），VSCode 面板里显示的缩略版（如
a1b2c3d）在某些 Git 版本下不可靠，优先用git log --oneline查看并复制 - 目标 commit 如果来自别人刚推上来的远程分支，你本地没
git fetch origin过，VSCode 终端里就查不到这个 hash——图形界面可能缓存了旧列表，但命令行不会骗你 - 想挑多个连续 commit？别用
cherry-pick A..B，VSCode 终端对双点语法支持不稳定；改用cherry-pick A^..B，或逐个 pick 更稳妥 - 挑完发现冲突？VSCode 会高亮冲突文件，但注意：此时
git status显示的是 “all conflicts fixed but not yet committed”，必须git add . && git cherry-pick --continue，否则下次cherry-pick会继承中断状态
这些命令本身不难，难的是 VSCode 的图形界面和终端行为不完全同步——比如面板里看到分支已切换，但终端里 git branch 还显示旧名，说明 VSCode 没触发 shell 的 pwd 更新；又比如 stash 列表在面板里清空了，但 git stash list 还有记录，说明你只点了面板里的删除，没执行 git stash drop。真要进阶，就得习惯两边对照着看。
