先运行 git status 确认真实冲突：Unmerged paths 是铁证，modified 无 both modified 说明已自动合并；VSCode 分块决策比手动删标记更安全；解决后必须运行测试+手动验证，不可仅依赖 git add。
确认冲突状态再动手
执行 git pull 或 git merge 报错后，别急着改代码。先运行 git status，看输出里有没有 Unmerged paths —— 这才是真冲突的铁证。如果只显示 modified 但没标 both modified，大概率是文件已自动合并成功，只是有未暂存改动。
常见误判：看到终端红字 CONFLICT (content): Merge conflict in app.js 就以为全盘崩了，其实 Git 只在真正无法判断的地方打标记，其余部分早默默合好了。
-
git status -uno能过滤掉未跟踪文件，聚焦冲突项 - 若输出含
both added或deleted by us，说明不是内容冲突，而是树冲突（比如一方删了文件，另一方改了它） - 别跳过这步直接开编辑器——有些“冲突”其实是
git fetch后忘了git merge，压根没触发合并流程
用 VSCode 内置对比界面分块决策
打开冲突文件，VSCode 会高亮显示三段式结构：<<<<<< HEAD 是你本地分支的修改，======= 是分隔线，>>>>>> feature/login 是要并入的分支内容。关键不是“删标记”，而是理解每段逻辑意图。
右键点击冲突区域，选 Accept Current Change / Accept Incoming Change / Accept Both Changes —— 这比手敲安全得多，尤其当冲突跨多行、含缩进或注释时，手动删标记极易漏掉半个 > 导致语法错误。
- 选
Accept Both Changes前务必检查顺序：比如一方加了if (loading) return;，另一方在下面调用fetchData()，直接拼一起会跳过请求 - 函数签名冲突（如参数名不同但语义一致）不能靠“接受全部”，得手动重写成兼容版本
- VSCode 底部状态栏会显示 “1 of 3 conflicts resolved”，别数错——大文件可能藏了多个冲突块
解决后必须验证，不能只靠 git add
git add app.js 只是告诉 Git “这段我搞定了”，不等于代码能跑。尤其涉及状态管理、API 调用链、CSS 类名等隐性依赖时，冲突修复可能破坏运行时行为。
验证顺序建议：先跑单元测试（npm test -- --testPathPattern=app.js），再本地启动服务点开对应页面，最后扫一眼控制台有没有新报错。曾有团队因合并时漏掉一行 import { useAuth } from './hooks'，所有登录页白屏，但 git status 显示干净，git commit 也顺利通过。
- 如果项目有 E2E 测试，至少手动走一遍核心路径（如登录→进首页→提交表单）
- 留意 ESLint 或 Prettier 自动格式化是否把冲突标记里的空格/换行吃了，导致实际保留了错误代码
- 别信
git diff --staged显示“只有业务代码变动”——二进制文件（如图片引用路径）冲突不会出现在这里
多人协作中复杂冲突要拆解沟通
当一个文件出现 5+ 处冲突，且涉及不同模块（比如同时改了权限校验、数据加载、UI 渲染三层逻辑），说明两个分支的修改边界已经模糊。这时候硬靠一个人拍板风险极高。
正确做法是：用 git log -p -n 5 app.js 查各自最近的修改提交，截图冲突块 + 对应 commit message 发到群聊，标注“此处 A 分支想解决 XX 问题，B 分支在处理 YY 需求，是否需要协同重构？”——把技术决策拉回需求层面，而不是在代码行上较劲。
- GitLab/GitHub 的 MR 页面点“Resolve conversation”能锁定某处讨论，避免后续人重复踩坑
- 拒绝“我先提个临时修复，回头再优化”的承诺——90% 的“回头”永远不会来，临时代码会变成技术债锚点
- 如果冲突涉及共享库或基础组件，优先约 15 分钟同步对齐，比花 2 小时各自猜对方意图更省时间
