VSCode 在 Git 合并冲突时显示“<<<<<<< HEAD”到“>>>>>>> [分支名]”的冲突标记。
Git 合并冲突时 VSCode 显示的“
这些标记不是 VSCode 加的，是 git merge 命令写入文件的冲突分隔符，VSCode 只是渲染出来。手动删标记不解决问题，反而可能破坏合并状态。
正确做法是：在 VSCode 编辑器里打开有冲突的文件 → 看顶部出现的「Accept Current Change」「Accept Incoming Change」「Accept Both Changes」等操作按钮 → 点击选择逻辑上正确的版本，VSCode 会自动清除所有 <<< HEAD、=======、>>> branch-name 标记，并保留你选中的内容。
- 如果点错了，可以右键文件标签 → 选「Revert Changes」回退到冲突前状态（前提是还没
git add） - 不要用全局搜索替换
<<< HEAD—— 它可能出现在注释或字符串里，误删会导致代码错误 - 接受完所有冲突后，必须执行
git add <file>，否则git status仍显示 unmerged
为什么 VSCode 的合并编辑器里看不到“传入更改”分支名
VSCode 的合并编辑器（Merge Editor）依赖 Git 当前的合并元数据。如果执行过 git merge --abort 或强制重置了 index，但残留了 .git/MERGE_HEAD 文件，就可能导致合并上下文丢失，分支名显示为空或为 unknown。
检查并清理的方法：
- 运行
git status，确认是否真处于合并中（应显示 “merging”） - 若显示 “not currently merging”，但文件仍有冲突标记，说明 Git 已退出合并流程，此时需手动恢复：先
git merge --continue（失败则git merge --abort再重试原命令） - 确认
.git/MERGE_HEAD文件存在且非空；若不存在，VSCode 就无法识别“传入更改”来源 - 某些 Git GUI 工具（如 GitHub Desktop）提前终止合并，也可能污染状态，建议统一用 CLI 触发合并
如何让 VSCode 自动打开合并编辑器而不是纯文本视图
VSCode 默认对 .js/.ts/.py 等常见类型启用合并编辑器，但对 .json/.md/.yml 等默认走文本模式。这不是 bug，是设计上的安全限制 —— 这些格式结构敏感，图形化合并易出错。
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
如确需开启，可在用户设置中加配置：
"git.mergeEditor": true,
并配合文件关联规则（推荐仅对确定安全的类型启用）：
"files.associations": {
"*.json": "jsonc",
"*.yaml": "yaml"
},
"git.mergeEditorFileExtensions": ["js", "ts", "py", "json", "yaml"]
-
git.mergeEditorFileExtensions是白名单，不在列表里的文件永远用文本视图 - 开启后，.json 文件若含数组/嵌套对象冲突，VSCode 仍可能因解析失败退回文本模式 —— 这是预期行为，别当成崩溃
- 团队协作时，避免在 settings.json 中硬编码该选项，改用工作区设置（.vscode/settings.json），防止影响他人
解决完冲突后 git commit 失败：提示“no changes added to commit”
这是最常被忽略的一步：VSCode 点了「Accept」只是改了文件内容，没通知 Git。Git 仍认为那些文件处于未暂存（unstaged）的冲突状态。
- 必须逐个执行
git add <file>，或全量git add .（注意别把不该提交的临时文件也加进去） - 运行
git status，确认所有冲突文件状态变成 “both modified” 下方的 “to be committed” - 如果用了
git add -u却没效果，说明文件尚未被 Git 跟踪（首次新增文件需git add -N或直接git add <file>） - VSCode 源代码管理面板右上角有个 “+” 图标，点击它可一键暂存所有已修改文件（包括刚解决冲突的），比敲命令更快
合并冲突本身不难，难的是状态感知 —— Git 的“当前是否在合并中”“哪些文件已解决但未暂存”“MERGE_HEAD 是否有效”，这几个点任何一个断掉，VSCode 的 UI 就会失联。与其反复试错，不如每次冲突前先 git status 看一眼，心里就有底了。
