用途：在把其他分支（通常是 main）整合进当前功能分支时使用，也适用于 merge 或 rebase 后 git status 显示未合并路径的情况。适用于任何基于 Git 的团队协作流程，Dune/React 应用中冲突常集中在应用外壳与共享库。
主要能力：目标是保留当前分支的有意改动，不默认“main 优先”或“ours 优先”；在编辑冲突前把取舍呈现给用户；按影响排序讨论，先结构/功能/API/数据模型，后样式、文案、间距。
硬性规则：不得静默解决——在用户同意方案（或明确说“按你的建议来”）之前，不要删除 <<<<<<< / ======= / >>>>>>> 标记，也不要对冲突文件执行 git add。遇到冲突即暂停并报告，除非用户明确要求，不要整文件选一边硬推。冲突按优先级分组：P0 结构/产品（删除路由、模块、功能、数据或 API 契约、SDK 或 schema、认证或路由外壳）；P1 行为（逻辑、hooks、查询、过滤、错误处理、加载状态）；P2 UI 结构（布局区域、新增或移除区块、导航）；P3 表现（token、间距、类名、文案）。
工作流：1) 优先 git fetch 后 git merge origin/main（除非用户要求 rebase）；若合并已进行，运行 git status 列出所有未合并文件。2) 明确报告冲突：当前分支、目标分支、merge 还是 rebase；未合并文件路径，可选 git diff --name-only --diff-filter=U；每个文件一行说明分歧点。3) 编辑前分析：结合对话历史、仓库信号（如 PRD.md、近期提交、文件归属）与冲突块（git show :2:path 与 git show :3:path），区分正交、重叠、损坏风险。4) 给出建议与问题：按 P0→P3 排序的表格或要点，标注推荐侧或“手动合并”及原因，提出歧义问题并请用户选择（如按建议、某文件保留分支、某文件保留 main、中止合并）。用户确认后再做小范围精准编辑，重跑 git status 确认无冲突标记，并运行相关测试或 lint。5) 用户想中止时用 git merge --abort 或 git rebase --abort，并确认会丢失该次整合状态。
反模式：未经批准对全仓库使用 --ours/--theirs；因 main 改了同一文件就删掉功能分支的工作；把冲突列表埋在长代码输出里；先修低影响样式冲突而把 P0 决策留作隐含。
快速参考：merge 中 stage 2 为当前分支（HEAD），stage 3 为传入分支（MERGE_HEAD），必要时用 git checkout --conflict=merge <file> 验证。全栈或 Dune 应用常见高冲突路径：根应用外壳、顶部导航、路由模块、共享 lib/ 或 hooks/。更多命令片段与合并信息模板见 reference.md。