vscode合并编辑器需手动保存并git add才能更新状态；current为当前分支修改（rebase时非head），incoming为对方改动；accept both changes仅拼接代码，不校验逻辑，易致重复定义或缺失依赖；解决冲突须清除全部标记，否则仍显示“conflicted”。
VSCode 内置合并编辑器能直接解决绝大多数文本类冲突，但必须手动保存并 git add，否则状态不会更新。
怎么打开合并编辑器并识别 CURRENT / INCOMING
冲突文件在源代码管理视图（Ctrl+Shift+G）中显示为“Conflicted”，点击即进入默认编辑模式；若未自动激活三栏视图，右键文件 → “Resolve in Merge Editor”即可打开。左侧窗格是 CURRENT（你当前分支的修改），右侧是 INCOMING（对方分支的改动），中间是可编辑的 RESULT 区域。
注意：CURRENT 不一定等于 HEAD —— 如果你在 rebase 过程中，CURRENT 实际对应的是待重放的提交，不是工作区最新 HEAD。
- 灰色背景行是双方都未改动的公共上下文，用于语义对齐，不可删除
- 红/绿边框高亮的是有差异的行，但不等于“必须处理”——只有被
等标记包围的块才算真正冲突 - 如果某段只在一侧有增删，另一侧无对应内容，VSCode 通常不标为冲突，而是直接合并（即“非重叠变更”）
Accept Both Changes 为什么有时会出错
点“Accept Both Changes”只是把左右两段代码按顺序拼进 RESULT，不做逻辑去重、变量重命名或执行顺序校验。常见翻车场景：
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 两边都新增了同名函数声明 → 合并后出现重复定义错误
- 左边删了
import React，右边加了import { useState }→ 拼接后缺失核心依赖 - 左边改了
if (x > 0)，右边改了if (x >= 0)→ 拼接不会自动取并集，而是变成两个 if 块
这类情况建议放弃一键操作，改用“手动编辑 RESULT 区域 + 删除全部冲突标记”，再逐行检查语法和语义一致性。
保存后文件还在 MERGE_CHANGES 列表里？
VSCode 只根据文件内容是否含冲突标记（、<code>=======、>>>>> feature-x）来判定是否解决。即使你点了“Accept Current Change”，只要没保存，或保存时残留了任意一行冲突标记，该文件就仍卡在“Conflicted”状态。
- 用
Ctrl+F搜确认是否清空 - 不要只删
和 <code>>>>>>，=======必须一并删除 - 某些插件（如 Prettier）可能在保存时自动格式化并插入空行，导致残留分隔符被误判为未清理
- 保存后立刻看源代码管理面板：文件从 “Conflicted” 移入 “Merged” 才算真正通过
批量接受策略的适用边界
Git: Accept Current Change 或 Git: Accept All Incoming Changes 这类命令面板操作，适用于整份文件所有冲突块都应统一取舍的场景，比如回滚某个功能分支、或强制覆盖本地调试代码。
- 它不区分冲突块粒度，一旦执行，全文件所有冲突区域都会被单侧覆盖
- 对 JSON/YAML 等结构化文件慎用——
Accept Current Change可能保留已废弃字段，而Accept Incoming Change可能丢掉新增必填项 - 执行后仍需手动
Ctrl+S保存，并运行git add <file></file>，VSCode 不会自动暂存
最易被忽略的一点：合并编辑器里的“Accept”按钮只作用于当前光标所在冲突块，而命令面板里的“Accept All…”是全局操作——别在没看清范围时连按两次。
