pull-changes-resolve-conflicts

拉取更改并解决合并冲突

在将其他分支（通常是 main）合并到当前功能分支时，或在合并或变基后 git status 显示存在未合并路径时，使用此技能。适用于任何基于 Git 的团队工作流；Fl​​ows/React 应用是常见场景，冲突通常集中在应用外壳和共享库中。

目标

• 保留当前分支上有意进行的工作；不要未经分析就假定“以 main 为准”或“以我们这边为准”。
• 在编辑解决冲突之前，先向用户说明权衡取舍。
• 按影响程度安排讨论顺序：先讨论结构、功能、API、数据模型变更，再讨论样式、文案或间距。

硬性规则

1. 不得静默解决冲突——在用户同意方案（或明确表示“采用你的建议”）之前，不得移除 <<<<<<< / ======= / >>>>>>>，也不得对存在冲突的文件运行 git add。
2. 遇到冲突即暂停——如果合并或变基引入了冲突，先暂停并报告；除非用户明确要求，否则不得不加分析地整份选用某一侧来处理大型文件。
3. 优先考虑影响——展示冲突时，大致按以下类别分组并排序：
   • P0 — 结构 / 产品： 删除路由、删除模块、移除功能、更改数据或 API 合约、SDK 或架构变更、身份验证或路由外壳。
   • P1 — 行为： 逻辑、钩子、查询、筛选器、错误处理、加载状态。
   • P2 — UI 结构： 布局区域、新增或移除的版块、导航。
   • P3 — 呈现： 设计令牌、间距、类名、文案调整。

工作流程

1. 拉取并集成（或诊断）

• 除非用户要求变基，否则优先运行 git fetch，然后运行 git merge origin/main（或指定的分支）。
• 如果合并已在进行中，运行 git status 并列出所有未合并文件。

2. 向用户报告冲突（明确说明）

输出清晰的列表：

• 分支状态： 当前分支、目标分支（例如 origin/main）、合并还是变基。
• 未合并文件： 仅列出路径，然后可选地运行 git diff --name-only --diff-filter=U。
• 逐个文件（简短说明）： 如果可根据路径和 git diff 推断，每个文件用一行说明差异内容（例如“AlertsPage — 布局 + 新数据范围”），且不得解决冲突。

3. 编辑前先分析

综合使用以下所有信息：

• 对话历史——用户或团队原本打算在此分支上交付什么？
• 仓库线索——如有，查看产品或架构文档（例如 PRD.md）、当前分支的近期提交、文件归属情况（例如大型功能模块还是共享 lib/）。
• 冲突区块——合并期间使用 git show :2:path（我们这边）和 git show :3:path（对方），或阅读冲突标记；识别重复变更与彼此独立的变更。

将每个冲突区域归类为：

• 彼此独立——可安全组合（例如导入排序 + 新属性）。
• 重叠——必须择一或手动合并（修改了相同的行）。
• 损坏风险——存在重复代码块（在不当合并后很常见）；应标记此风险，并建议以一侧为基础重构，再手动重新应用另一侧的意图。

4. 提出建议并提问（必需）

向用户提供：

1. 摘要表格或要点——文件 → 建议采用哪一侧或“手动合并”→ 一句话说明理由。
2. 按 P0 → P3 排序——优先指出任何移除功能或更改公开行为的情况。
3. 明确提问——说明任何模糊之处（例如：“保留 main 的全局行为，还是分支上的范围限定版本？”）。
4. 征求指示——例如：“请回复：(a) 按建议处理，(b) 文件 X 保留分支版本，(c) 文件 Y 保留 main 版本，(d) 中止合并。”

只有在用户确认（或给出明确的文件对应处理方式）之后，才能应用解决方案：

• 优先进行小范围、精准的编辑；尽可能保留双方意图。
• 重新运行 git status；确保不再有冲突标记；对涉及的部分运行用户关心的测试或 lint。

5. 如果用户想要中止操作

• 根据情况执行 git merge --abort 或 git rebase --abort；确认用户了解，这会丢失该操作进行中的集成状态。

反模式（不要这样做）

• 未经用户批准，就对整个仓库选择 --ours / --theirs。
• 因为主分支修改了同一文件，就通过删除功能分支上的工作来“解决”冲突。
• 把冲突列表藏在冗长的代码转储中，却不提供简短的摘要。
• 优先处理影响较小的样式冲突，却让 P0 决策含糊不清。

快速参考

• 合并时的 ours 与 theirs： 阶段 2 = 当前分支（HEAD），阶段 3 = 传入分支（MERGE_HEAD）。如有需要，使用 git checkout --conflict=merge <file> 进行验证。
• 全栈或 Flows 应用中常见的高频冲突路径： 根应用外壳、顶部导航、路由模块，以及共享的 lib/ 或 hooks/。

可选的命令片段和合并消息模板，请参阅 reference.md。