VSCode源控制面板是驱动Git工作流的图形中枢，需理解各区域对应的真实Git语义；冲突解决须依❗图标、MERGE CHANGES分组、编辑器黄色提示条及<<<、===、>>>标记三重确认；部分暂存仅支持连续文本块；分支切换受Git保护机制限制；“Accept Both”可能引发语法错误，应优先使用合并编辑器手动去重；解决冲突后必须手动暂存文件。
VSCode 的版本控制视图（Source Control 面板）不是“只用来点提交”的装饰面板，它是一套可直接驱动 Git 工作流的图形化操作中枢——关键在于理解每个区域对应的真实 Git 操作语义，否则容易误点、漏提交或残留冲突。
如何识别并进入真正的冲突解决模式
冲突不是靠“弹窗”提醒，而是靠状态标记和编辑器行为双重确认：
-
资源管理器中文件名旁出现
❗图标，且在MERGE CHANGES分组下显示为Conflicted - 打开该文件后，编辑器顶部出现黄色提示条：“正在解决合并冲突”，同时代码中出现
<<<<<< HEAD、=======、>>>>>> feature/login三段结构 - 此时若未启用内联控件，光标悬停在冲突块上会浮现小按钮；若已启用
git.inlineMergeControls，每行末尾直接显示✓ 当前、✓ 传入、✓ 两者
常见错误：看到红标就急着点“接受当前”，却没注意该文件其实还包含另一处未高亮的冲突块（尤其在长配置文件中）。务必滚动全文搜索所有 <<<<<< 标记。
部分暂存（Stage Selected Ranges）的实际用途与限制
这不是“高级功能彩蛋”，而是日常避免污染提交的刚需操作——尤其当你改了一个函数但顺手调了两行 debug log 或改了注释格式时：
- 在“更改”列表中点击文件，进入差异视图
- 右键某一块绿色新增内容 → 选择
Stage Selected Ranges，仅暂存该区块；其余修改仍留在“未暂存更改”区 - 对含逻辑变更+格式调整的文件，可先暂存业务代码，再单独处理空行/缩进，最后丢弃调试语句
注意：Stage Selected Ranges 不支持跨函数暂存（比如选中函数 A 的开头和函数 B 的结尾），VSCode 会自动截断为连续文本块。若需更细粒度，必须用命令面板执行 Merge Conflict: Edit Manually 后手动删标记再暂存。
分支切换失败时，VSCode 真正在阻止什么
状态栏分支名点击后弹出“无法切换：存在未暂存的更改”，这不是 Bug，是 Git 的硬性保护机制：
- VSCode 检测到工作区有未
git add的修改，且这些修改在目标分支中不存在（或内容不同），强行切换会导致覆盖丢失 - 你只有三个合法路径：①
Discard Changes（永久删除本地修改）；②Stash Changes（压栈保存，切换后再Pop）；③ 先Stage再Commit（把当前进度固化为一次提交） - 误操作高发点：点了
Discard Changes却没看清右侧预览框里要删的是哪几行——建议开启设置git.showUncommittedChangesInDiffView，让丢弃前强制显示 diff 预览
为什么“Accept Both Changes”有时反而导致编译失败
这个按钮不智能合并逻辑，只是机械拼接文本——当双方都新增了同一 import 或重复定义了同名变量时，会直接生成语法错误：
- 例如：当前分支加了
import { foo } from './utils';，传入分支也加了import { foo, bar } from './utils';，选“接受两者”会变成两行 import - 再如：两个分支都在函数开头加了
console.log('start');，“接受两者”会在同一位置插入两次 - 真正安全的做法是：先点
Open Merge Editor进入三栏视图，左侧看当前分支、右侧看传入分支、中间手动编辑去重整合，最后保存
最易被忽略的一点：解决完所有冲突后，VSCode 不会自动帮你 git add。必须回到 Source Control 面板，确认文件已移至“已暂存更改”区（绿色图标），再输入提交信息并点击勾号——漏掉这步，merge 就卡在半途，下次 pull 仍会报冲突。
