“接受传入的更改”在 VSCode 中对应 Accept Incoming 操作，即丢弃当前分支（HEAD）修改，完全采用被合并分支的代码；需逐块确认或通过命令面板批量执行，并验证无残留冲突标记及业务逻辑正确性。
Git 合并冲突时，“接受传入的更改”在 VSCode 里对应哪个操作
VSCode 内置的合并编辑器里没有直接叫“只保留传入的更改”的按钮，它实际对应的是 Accept Incoming 操作——也就是丢弃当前分支（HEAD）的修改，完全采用被合并分支（比如 main 或 feature-x）的代码。
这个动作常被误点成 Accept Current，结果把冲突留着没解决，或者把本该更新的逻辑又回退了。
- “传入的更改” = 对方分支的改动，即
git merge命令中你正在合并进来的那个分支的变更 - “当前更改” = 你本地所在分支（通常是
HEAD）已有的代码，不是“最新版”，而是你 checkout 进去时的状态 - VSCode 状态栏右下角会显示当前处于“Merge Conflict”模式，并列出冲突文件；点开后左侧是
Current Change，右侧是Incoming Change
怎么安全、准确地执行 Accept Incoming（且不漏文件）
手动逐个点击每个冲突块的 Accept Incoming 按钮看似简单，但容易跳过嵌套冲突或忽略未打开的冲突文件。真正可靠的做法是结合命令行与 UI：
- 先运行
git status，确认所有冲突文件都列在 “Unmerged paths” 下；VSCode 只高亮已打开的文件，未打开的不会自动提示 - 对单个文件，在编辑器里右键冲突区域 → 选
Accept Incoming；不要用 Ctrl/Cmd+Click 快捷键，因为默认绑定可能是Accept Both - 想批量处理整个文件：打开该文件 → 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac）→ 输入 “Merge Conflict: Accept Incoming” → 回车，整份文件立刻替换成传入版本 - 如果已经误点了
Accept Current，别急着git add，直接关掉文件再重新打开，冲突会重载（前提是还没git add）
为什么有时候 Accept Incoming 后 git status 还显示冲突
常见原因是 VSCode 没有真正完成“标记为已解决”。Git 是否认为冲突已解决，只看文件内容是否还包含 / <code>====== / >>>>>> 这类标记，而不是看 VSCode 界面有没有变绿。
- 检查文件末尾或中间是否残留了未处理的冲突标记——尤其当文件很长、VSCode 自动折叠了部分区域时，很容易漏看
- 运行
git diff --check，如果有输出类似 “foo.js: 1 line adds whitespace error”，说明文件虽无冲突标记，但可能因格式问题被 Git 拒绝提交 - 确保你执行的是
git add <file></file>，不是git add .——后者可能把还没清理完的其他冲突文件也一起暂存，导致git commit失败并报错error: 'foo.js' appears as both a file and a directory（罕见但真实）
接受传入更改后，要不要再跑一遍测试
要。这不是谨慎，是必须。因为 Accept Incoming 本质是强制覆盖本地逻辑，哪怕只是改了一行日志，也可能影响条件判断、API 调用顺序或状态初始化时机。
- 尤其注意副作用明显的场景：React 组件的
useEffect依赖数组、Node.js 中间件注册顺序、数据库 migration 文件里的up()函数 - 如果项目开了 pre-commit hook（比如
lint-staged），它会在git add后自动触发；但 hook 不会帮你发现业务逻辑被意外替换的问题 - CI 流水线失败的第一条线索，往往就是某次合并后某个单元测试的
expect断言突然不通过——而开发机上没跑测试就直接 push 了
冲突解决不是终点，是验证起点。最常被跳过的，就是打开终端敲下 npm test 或 pytest 的那一下。
