VSCode 不支持自动合并分支，仅在无冲突时跳过手动编辑；真正提升效率的是 GitLens（行级 blame 分析）、ESLint+Prettier（合并后即时校验）、Auto Save 配合手动暂存习惯，以及理解 CURRENT/INCOMING 在 rebase 中的真实语义。
VSCode 本身不提供“自动合并代码分支”的能力，所谓“自动”只是指在无冲突时跳过手动编辑环节，但 Git 合并逻辑、HEAD 指向、提交生成等关键步骤仍需你明确触发和确认。真正能降低协作门槛的，是一组插件 + 正确操作习惯的组合。
GitLens：看清谁改了哪行，避免盲目 Accept Incoming
默认 VSCode 的 Git 面板只显示文件级变更，而 GitLens 能在行号旁直接标注每行代码最后是谁、什么时候、在哪个提交里改的。这对判断冲突该信哪边极其关键——比如你看到 config.timeout = 5000 是上周自己加的，而对方改的是 config.baseURL，那冲突块里保留 timeout、接受 baseURL 就很合理。
- 安装后无需配置，默认启用 blame 注释；按
Alt+Click（Mac 为Option+Click）某行可快速跳转到对应提交 - 在冲突文件中右键 →
GitLens: Compare With Branch可对比当前分支与 incoming 分支在该文件上的完整差异，比只看冲突块更安全 - 注意：它不替代合并操作，只是帮你做决策；如果禁用了
git blame缓存（如设了gitlens.advanced.blame.ignoreRevsFile），首次加载可能稍慢
ESLint + Prettier：合并后立刻暴露格式/语法问题，别等 CI 报错
合并冲突时点 Accept Both Changes 很容易导致重复 import、多行 const 声明或缺失分号。靠肉眼很难扫全，而 ESLint 和 Prettier 在保存瞬间就能标出错误。
- 必须关掉
ESLint的格式化功能："eslint.format.enable": false，否则会和Prettier抢着改代码，造成光标乱跳或格式反复 - 推荐在项目根目录配
.eslintrc.cjs，extends里按顺序写'eslint:recommended','prettier'，确保 prettier 规则最终生效 - 合并完所有冲突文件后，批量保存（
Ctrl+K S）——这时 ESLint 会实时报Duplicate declaration，Prettier 会自动把拼在一起的两行函数缩成一行，你能立刻回退修正
Auto Save + Format On Save：不是“自动合并”，而是“防手滑漏提交”
很多人以为合并完成就结束了，结果发现文件还卡在 Merge conflict 状态。根本原因是：VSCode 解决冲突后只改内容，不自动 git add，而你又没手动点 + 或执行命令。
- 开启
files.autoSave（建议设为onFocusChange），确保编辑器失去焦点时自动保存，避免改完忘存 - 但
Format On Save对冲突文件要小心：如果 Prettier 把你刚手动修好的对象结构又格式化回多行，可能意外引入空格或换行导致新冲突。建议冲突解决阶段临时关闭该选项 - 真正关键的是养成习惯：解决完一个冲突文件 → 保存 → 看源代码管理面板里该文件是否从
Conflicted变成Staged（有+号）；没变就手动点+，别依赖“保存即暂存”
最易被忽略的其实是 CURRENT 和 INCOMING 的语义——在 rebase 场景下，CURRENT 不是当前 HEAD，而是待重放的旧提交。这时候点 Accept Current Change 可能把你刚删掉的 bug 又加回来。遇到复杂合并，先看一眼 git log --oneline --graph 确认当前 HEAD 和共同祖先位置，比猛点按钮靠谱得多。
