VSCode Source Control 面板是轻量级操作入口，仅管理暂存区（index），不替代 Git GUI；Stage/Unstage 不影响工作目录，仅控制下次提交内容；分支切换需区分 Checkout to（切换已有分支）与 Create Branch（新建并可选检出）；Push/Pull 默认依赖 origin 和已配置的 upstream；状态异常时应优先使用 git status 等命令诊断。
VSCode 的 Source Control 面板不是 Git GUI 替代品，而是轻量级操作入口——它能干的有限，但干得对路时效率很高；乱点一通反而容易丢暂存、切错分支、提交到错的 remote。
点击 Stage Changes 和 Unstage Changes 到底在动什么
这两个按钮只影响 Git 的“暂存区（index）”，不碰工作目录文件内容，也不触发提交。你改了 app.js，它默认显示在“Changes”列表里；点 Stage Changes 后会移到“Staged Changes”里——这意味着下次 git commit 会包含它。
- 常见错误现象：
git status显示有修改，但 VSCode Source Control 面板空空如也 → 文件被.gitignore忽略，或仓库根路径没识别对（检查左下角源控状态栏是否显示正确 repo 路径） - 使用场景：只想提交部分改动（比如修 bug 的代码 + 对应测试，但不提交调试用的
console.log）→ 单独勾选文件再点Stage Changes - 注意：
Unstage Changes不等于撤销修改，只是把已暂存的文件从 index 移回 working directory；想丢弃修改得右键文件选Discard Changes
分支切换时 Checkout to 和 Create Branch 的实际行为差异
点 Checkout to 是执行 git checkout <branch></branch>（或 git switch <branch></branch>），要求目标分支已存在；而 Create Branch 默认执行 git checkout -b <name></name>，基于当前 HEAD 新建并检出。
- 容易踩的坑：在“未追踪文件”状态下点
Create Branch，新分支会带上这些文件；但若原分支还没提交过，这些文件其实在新分支里也是 untracked 状态，容易误以为“继承了全部改动” - 参数差异：
Create Branch弹窗里勾选Checkout branch才真正切换；不勾就是只创建不检出，面板顶部分支名不会变 - 性能影响：切换大量未提交变更的分支时，VSCode 可能卡顿几秒——不是它慢，是 Git 在做 worktree 冲突检测；建议先
git stash或暂存关键改动再切
Push / Pull 按钮背后默认走哪个 remote 和 refspec
VSCode 默认只认 origin 这个 remote 名，且 push/pull 都基于当前分支的 upstream 设置（即 git branch --set-upstream-to=origin/main main 配置后才有效）。没设 upstream 时，Push 会弹窗让你选 remote 和 target branch。
- 常见错误现象：“Push failed: No configured upstream branch” → 当前分支没关联远程分支，不能一键推；解决方法是先点
Push弹窗里选origin和对应远端分支，或终端执行git push -u origin <branch></branch> - 使用场景：团队用多个 remote（比如
origin和upstream）时，VSCode 不提供下拉选 remote 的 UI，必须手动配好 upstream，否则只能靠终端 - 兼容性注意：VSCode 1.85+ 对
git.push.followTags支持有限，打 tag 后点Push不会自动推 tag，得开终端补git push --tags
Source Control 面板最脆弱的地方，是它把 Git 的多层状态（working tree / index / HEAD / remote tracking）压缩成两栏加几个按钮。一旦分支有冲突、rebase 中断、或者 .git/config 里 upstream 写错，UI 就会静默失效——这时候别硬点，git status 和 git log --oneline --all --graph 才是你该看的第一眼。
