VSCode合并编辑器仅在git merge/pull导致文件处于unmerged状态时激活；若手动修改未add、用外部工具或Git扩展异常，界面将不显示，需检查git status、Git扩展及项目根目录。
Git 合并冲突时，VSCode 为什么没弹出合并编辑器
不是所有冲突都会自动触发 VSCode 的可视化合并界面——它只在 git merge 或 git pull 导致冲突、且工作区文件被标记为“unmerged”状态时才激活。如果手动修改了冲突文件但没运行 git add，或用外部工具（如命令行 git mergetool）跳过了默认流程，VSCode 就不会介入。
实操建议：
- 确保冲突发生后，先执行
git status，确认文件出现在Unmerged paths区域 - 不要直接保存并关闭冲突文件；VSCode 只在检测到
.git/下有未解决的 index entry 时才渲染合并控件 - 若已误操作，可运行
git checkout --ours/--theirs <file>回退再重试，避免残留冲突标记干扰
点开冲突文件后，VSCode 合并控件不显示或灰色不可点
常见原因是当前文件未被 Git 跟踪，或 VSCode 没识别到该文件处于冲突状态。VSCode 的合并 UI 依赖 Git 扩展读取 git ls-files -u 输出，一旦缓存失效或扩展未启用，控件就消失。
实操建议：
- 检查左下角状态栏是否有
Git图标和分支名；没有则点击它，选择“Initialize Repository”或确认 Git 扩展已启用 - 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac），输入Git: Show Git Output，查看是否报错fatal: not a git repository - 重启 VSCode 并打开项目根目录（含
.git文件夹的路径），不要只打开单个文件
如何快速接受“传入更改”或“当前更改”，而不手动删标记
VSCode 提供了右键菜单和命令面板两种快捷方式，比手动删 <<<</======/>>>> 安全得多——它们会同步更新 Git index 状态，避免后续 git add 失败。
实操建议：
- 右键冲突块 → 选
Accept Current Change（保留你本地的）或Accept Incoming Change（用远端的） - 或按
Ctrl+Shift+P→ 输入Merge Conflict: Accept→ 选对应操作 - 注意：若一个文件有多个冲突块，需逐个处理；批量操作只在全部接受同一侧时才安全（比如
git checkout --theirs .后再git add .）
合并后 git status 还显示冲突文件，但内容里没
这说明你用了“接受某一方”功能，但忘了 git add <file>。VSCode 不会自动执行 git add，它只改文件内容；Git 仍认为该文件处于未解决状态，直到你明确把它加入暂存区。
实操建议：
- 每次解决完一个文件，立刻在 VSCode 中右键 →
Stage Changes，或终端执行git add <file> - 用
git status -s快速核对：冲突文件前应是UU（unmerged），解决并add后变成MM（modified）或空行 - 别依赖“文件已干净”就关掉——VSCode 编辑器标签页右上角的圆点消失 ≠ Git 状态已更新
最常被忽略的一点：VSCode 的合并控件只响应 Git 原生命令触发的冲突，不接管 IDE 内部的“保存即覆盖”行为。一旦你绕过 Git 直接写文件，冲突逻辑就断了，只能靠 git restore --staged 或重置索引来补救。
