VSCode Git面板是git命令的可视化封装，非黑盒：点击“+”仅添加未跟踪文件，Stage All等同git add .，Sync执行pull+push但默认变基，分支切换需先处理未提交更改，冲突解决后必须手动Stage才能提交。
VSCode 的 Git 面板不是“命令行替代品”，而是对 git 命令行为的直接封装——它调用的是你系统里真实的 git 二进制，所有操作都可被终端复现、可被脚本接管、也受 .gitconfig 和钩子约束。别把它当黑盒，否则遇到问题只会干瞪眼。
点一下就提交？先看清楚 git add 实际加了什么
VSCode 界面里点击文件旁的 + 或执行 Git: Stage All，本质就是运行 git add。但默认行为有陷阱：
-
git add .（对应“Stage All”）会递归添加当前目录下所有已修改/新建文件，包括你临时生成的logs/、dist/或 IDE 自动生成的.vscode/——只要没被.gitignore明确排除，就会进暂存区 - 右键单个文件选
Stage Changes，只对那个文件生效；但若该文件已被部分暂存（比如用过Stage Selected Ranges），再次点击会把剩余未暂存改动也一并加入 - VSCode 不显示“部分暂存”状态的视觉提示，容易误判。建议在终端跑一次
git status --short对照确认
Sync 按钮不是万能的，它等于 pull + push，但顺序和冲突策略不可控
底部状态栏的 Sync 按钮看起来省事，但它背后是固定流程：先 git pull --rebase（或 --ff-only，取决于设置），再 git push。问题在于：
- 如果远程有新提交，而你本地有未推送的 commit，
Sync默认尝试变基（rebase）。一旦变基过程中出现冲突，VSCode 会停在合并编辑器，但不会自动git add冲突解决后的文件——你得手动暂存，否则push会失败 - 它不支持
--no-ff合并策略，也没法指定pull时是否 fetch 所有分支（git fetch --all） - 团队若约定必须用 merge 提交（保留分支拓扑），
Sync就不该用，应拆成手动Pull→ 解决冲突 →Commit→Push
分支切换失败？大概率是工作区有未暂存/未提交的修改
VSCode 底部点击分支名 → Checkout 失败，弹窗报 “There are uncommitted changes” 或 “Please commit or stash them first”，这不是 bug，是 Git 保护机制：
- Git 要求切换分支时，工作区和暂存区必须与目标分支 HEAD 一致（或至少不冲突）。哪怕只是改了一行空格，也会阻断切换
- VSCode 不会自动帮你
stash，也不会弹窗问“要暂存还是丢弃”。你得自己决定：右键文件选Discard Changes，或用命令面板运行Git: Stash，或先Stage+Commit - 注意：
Discard Changes是硬删除，不可撤回；Stash存的是快照，之后可用Git: Stash Pop恢复，但可能再次触发冲突
冲突标记没消失？检查你是否漏掉了 git add 这一步
合并或拉取后，VSCode 编辑器里出现 <<<<<< HEAD 这类标记，说明 Git 已识别冲突，但尚未完成“解决”。关键点：
- 你手动删掉标记、保留某方代码、保存文件，这只是编辑器层面的操作——Git 仍认为该文件处于“未解决冲突”状态
- 必须在源代码管理视图中右键该文件，选
Stage Changes（或按Ctrl+Enter），才算真正告诉 Git “我搞定了” - 如果跳过这步直接点
Commit，VSCode 会拒绝提交，并高亮提示 “Conflicted files must be staged before committing” - VSCode 的合并编辑器（Merge Editor）右侧的
Accept Current Change/Accept Incoming Change按钮，点完仍需手动Stage，它不自动触发git add
Git 在 VSCode 里没有魔法，只有确定的行为链：修改 → add → commit → push。每个界面按钮背后都是一个明确的命令，而每个命令都有其前置条件和副作用。最常出问题的地方，永远是“以为点了就完事”，却忽略了中间那层必须由人确认的状态跃迁。
