vscode处理git合并冲突的核心是三向对比视图，需满足git.mergeeditor为true、项目根目录含.git且文件处于unmerged paths状态；视图左栏为current change（head分支）、中栏为common ancestor（共同祖先版本）、右栏为incoming change（待合并分支），result栏为手动编辑区，accept both仅拼接文本不校验逻辑，解决后必须执行git add才真正结束冲突。
VSCode 处理 Git 合并冲突的核心能力就藏在它的三向对比视图里——不是靠删标记硬扛，而是用 Current、Common Ancestor、Incoming 三栏结构把“谁改了什么、为什么不能自动合并”直接摊开给你看。只要 git.mergeEditor 开启且文件状态是 Unmerged paths，这个视图就会生效，否则你看到的只是带按钮的内联冲突块，不是真三路。
确认三向对比视图已启用并触发
很多人点开冲突文件却只看到上下两段高亮，是因为 VSCode 没进入真正的三向合并模式。它不是默认总打开的，必须满足三个硬条件：
-
git.mergeEditor设置为true（VSCode 1.84+ 默认开启，但旧工作区可能仍为false；按Ctrl+,搜该配置项确认） - 项目根目录下存在
.git，且当前工作区就是仓库根（子文件夹打开会失效） - 终端执行
git status显示文件在Unmerged paths下，而非仅Untracked files或modified
最稳的唤起方式：在源代码管理面板（Ctrl+Shift+G）中右键冲突文件 → 选 Resolve in Merge Editor。如果弹出的是双栏（Current/Incoming），说明共同祖先没加载出来——大概率是文件编码非 UTF-8（比如含 GBK 中文注释）或 Git 版本低于 2.25。
理解三栏内容的真实含义
三向视图中间那栏叫 Result，但它不是“自动合成结果”，而是你手动编辑的画布；左右两栏也不是“我的 vs 他的”，而是有明确语义的版本源：
- 左栏 =
Current Change：你当前检出分支（HEAD）的修改，比如你在main上拉取feature/login，这栏就是main的最新提交 - 中栏上部 =
Common Ancestor：两个分支最后一次共同提交的内容，它是判断“哪行被谁改过”的基准，VSCode 用灰色弱化显示，千万别忽略它 - 右栏 =
Incoming Change：正要合并进来的分支（如feature/login）的变更，不是远程 origin 的快照，而是该分支 tip 的 diff
常见误判：看到左右都改了同一函数，就以为必须二选一。其实得先看中栏——如果中栏该函数是空的，说明两边都是新增，Accept Both 可能合理；如果中栏有原始逻辑，而左右分别删了一半，那就要手动重写，不能拼接。
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
慎用 Accept Both Changes：它不校验逻辑，只拼接文本
Accept Both Changes 按钮本质是把左栏全部内容 + 右栏全部内容按顺序写进 Result 区，中间加个空行。它对以下场景极危险：
- 两边都加了
import React from 'react'→ 结果出现重复 import - 左栏改
config.timeout = 5000，右栏改config.timeout = 10000→ Result 区两行赋值，后者覆盖前者，但业务意图丢失 - 左栏是
if (user.role === 'admin')，右栏是if (user.permissions.includes('write'))→ 拼成两个独立 if，而非合并权限判断逻辑
真正需要融合的地方（比如一个分支加字段校验、另一个改返回结构），必须手动删掉所有 、<code>=======、>>>>>> feature-x 标记，在 Result 区重写逻辑。VSCode 不会帮你做语义合并，只负责呈现和搬运。
解决后必须 git add，否则冲突未真正结束
点击 Accept Merge 或手动编辑保存后，VSCode 编辑器里的冲突标记会消失，状态栏也可能提示 “All merge conflicts resolved”，但这只是编辑器层面的清理。Git 仍认为文件处于未解决状态，直到你执行：
git add <filename></filename>
否则运行 git commit 会报错：fatal: cannot lock ref 或 error: 'xxx' is not ready to be committed。更隐蔽的坑是：如果用 SCM 面板顶部的 ✓ Commit 按钮，它会自动 git add 所有已修改文件——但如果你之前 git add 过其他非冲突文件，这次提交会把它们也带上，容易混入意外变更。建议始终在终端明确执行 git add <conflicted-file></conflicted-file>，再提交。
