多人协作分支合并时如何安全拉取 main…

在多人协作的 Git 项目中把 main 或其他分支合并进当前特性分支、或 git status 出现未合并路径时，先分析冲突再让用户决策，避免静默丢弃任何一方的工作。

适用场景

解决思路

1. 优先执行 git fetch 后再 git merge origin/main（或指定分支），除非用户明确要求 rebase。
2. 若合并已在进行中，运行 git status 并列出每一个未合并文件。
3. 向用户明确报告冲突：当前分支、目标分支（如 origin/main）、是 merge 还是 rebase；未合并文件路径（可用 git diff --name-only --diff-filter=U）；每个文件用一行简述分歧内容（如“AlertsPage — 布局 + 新数据范围”），但不要在此阶段解决冲突。
4. 编辑前先分析：结合对话历史（团队在本分支想交付什么）、仓库信号（PRD.md 等产品/架构文档、当前分支近期提交、文件归属如大型功能模块 vs 共享 lib/）、以及冲突片段（合并中用 git show :2:path 看 ours、git show :3:path 看 theirs，或直接读冲突标记），区分重复改动与正交改动。
5. 把每个冲突区域分类为：正交（可安全合并，如 import 排序 + 新 prop）、重叠（必须二选一或手工合并同一批行）、损坏风险（重复代码块，常见于错误合并；应标记并建议从一侧重建后手工重新应用另一侧的意图）。
6. 向用户给出建议与问题：文件 → 推荐采用哪一侧或“手工合并” → 一行理由；按 P0→P3 排序，先指出任何删除功能或改变公开行为的地方；对含糊之处提出明确问题（如“保留 main 的全局行为还是分支的作用域变体？”）；并请用户给出方向（如回复：(a) 按建议执行，(b) 文件 X 保留分支版本，(c) 文件 Y 保留 main 版本，(d) 中止合并）。
7. 只有在用户确认（或给出精确映射）之后才应用解决方案：优先做小而精准的编辑，尽量保留双方意图；重新运行 git status 确认没有残留冲突标记；对受影响区域运行用户关心的测试或 lint。
8. 若用户想中止：按情况执行 git merge --abort 或 git rebase --abort，并确认他们会丢失该次操作的进行中集成状态。
9. 冲突优先级排序参考：P0 结构性/产品级（删除的路由、删除的模块、丢失的功能、变更的数据或 API 契约、SDK 或 schema 变更、认证或路由外壳）；P1 行为（逻辑、hooks、查询、过滤器、错误处理、加载状态）；P2 UI 结构（布局区域、新增或删除的区块、导航）；P3 表现层（token、间距、类名、文案微调）。
10. 区分 ours 与 theirs（merge 场景）：stage 2 = 当前分支（HEAD），stage 3 = 传入分支（MERGE_HEAD）；必要时用 git checkout --conflict=merge <file> 验证。
11. 注意全栈或 Flows 应用中常见的高冲突路径：根应用外壳、顶部导航、路由模块、共享 lib/ 或 hooks/。

适用边界 · 注意事项

• 不要在没有用户批准的情况下对整个仓库选择 --ours 或 --theirs。
• 不要因为 main 改动了同一文件就删除特性分支的工作来“解决”冲突。
• 不要在用户同意方案（或明确说“按你的建议来”）之前删除冲突标记或对冲突文件执行 git add。
• 不要在遇到冲突时不停下来报告就直接硬推过去，除非用户明确要求整文件选边。