pull-changes-resolve-conflicts

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pull changes & resolve merge conflicts

拉取变更并解决合并冲突

Use this skill whenever integrating another branch (usually

main

) into the current feature branch, or when

git status

shows unmerged paths after a merge or rebase. Applies to any Git-based team workflow; Dune/React apps are a common case where conflicts cluster in app shells and shared libraries.

在将其他分支（通常为

main

）集成到当前功能分支时，或者

git status

显示合并/变基后存在未合并路径时，使用此技能。适用于任何基于Git的团队工作流；Dune/React应用是冲突集中出现在应用壳层和共享库中的常见场景。

Goals

目标

Preserve intentional work on the current branch; do not assume “main wins” or “ours wins” without analysis.
Make trade-offs visible to the user before any conflict resolution edits.
Order discussion by impact: structural / feature / API / data-model changes before styling, copy, or spacing.

保留当前分支上的有意工作内容；未经分析，请勿默认“main分支优先”或“本地分支优先”。
在进行任何冲突解决编辑之前，让用户清晰看到权衡方案。
按影响程度排序讨论内容：结构/功能/API/数据模型变更优先于样式、文案或间距调整。

Hard rules

硬性规则

No silent resolution — Do not remove
```
<<<<<<<
```
/
```
=======
```
/
```
>>>>>>>
```
or run
```
git add
```
on conflicted files until the user has agreed to the plan (or explicitly says “use your recommendations”).
Stop at conflicts — If a merge or rebase introduces conflicts, pause and report; do not bulldoze through large files by picking one side wholesale unless the user explicitly requests that.
Prioritize impact — When presenting conflicts, group and order roughly as:
- P0 — Structural / product: removed routes, deleted modules, dropped features, changed data or API contracts, SDK or schema changes, auth or routing shell.
- P1 — Behavior: logic, hooks, queries, filters, error handling, loading states.
- P2 — UI structure: layout regions, new or removed sections, navigation.
- P3 — Presentation: tokens, spacing, class names, copy tweaks.

禁止静默解决——在用户同意方案（或明确表示“采用你的建议”）之前，不得移除
```
<<<<<<<
```
/
```
=======
```
/
```
>>>>>>>
```
标记，也不得对冲突文件执行
```
git add
```
操作。
遇到冲突即暂停——如果合并或变基引入冲突，暂停并上报；除非用户明确要求，否则不得通过全盘选择某一方内容来强行处理大文件。
按影响优先级排序——展示冲突时，大致按以下分组和顺序排列：
- P0 — 结构/产品层面：路由移除、模块删除、功能下线、数据或API契约变更、SDK或Schema变更、权限或路由壳层修改。
- P1 — 行为层面：逻辑、钩子（hooks）、查询、过滤器、错误处理、加载状态。
- P2 — UI结构层面：布局区域、新增或移除的版块、导航。
- P3 — 展示层面：令牌（tokens）、间距、类名、文案微调。

Workflow

工作流

1. Fetch and integrate (or diagnose)

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

Prefer
```
git fetch
```
then
```
git merge origin/main
```
(or the named branch) unless the user asked for rebase.
If merge is already in progress, run
```
git status
```
and list every unmerged file.

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

2. Report conflicts to the user (explicit)

2. 向用户明确上报冲突

Output a clear list:

Branch state: current branch, target branch (e.g.
```
origin/main
```
), merge vs rebase.
Unmerged files: paths only, then optionally
```
git diff --name-only --diff-filter=U
```
.
Per file (short): one line on what diverged (e.g. “
```
AlertsPage
```
— layout + new data scope”) if inferable from paths and
```
git diff
```
without resolving.

输出清晰的列表：

分支状态：当前分支、目标分支（如
```
origin/main
```
）、合并还是变基。
未合并文件：仅路径，可选择性附上
```
git diff --name-only --diff-filter=U
```
的结果。
每个文件的简要说明：如果能从路径和
```
git diff
```
中推断出差异内容（无需解决冲突），用一行描述（如“
```
AlertsPage
```
— 布局调整 + 新数据范围”）。

3. Analyze before editing

3. 编辑前先分析

Use all of:

Conversation history — What was the user or team trying to ship on this branch?
Repo signals — Product or architecture docs if present (e.g.
```
PRD.md
```
), recent commits on the current branch, file ownership (e.g. large feature module vs shared
```
lib/
```
).
Conflict hunks —
```
git show :2:path
```
(ours) vs
```
git show :3:path
```
(theirs) during merge, or read conflict markers; identify duplicated vs orthogonal changes.

Classify each conflicted area as:

Orthogonal — safe to combine (e.g. import sort + new prop).
Overlapping — must choose or manually merge (same lines).
Corruption risk — duplicated blocks (common after bad merges); flag and recommend reconstructing from one side then re-applying the other side’s intent manually.

综合利用以下所有信息：

对话历史：用户或团队在当前分支上试图交付的内容是什么？
仓库信号：若存在产品或架构文档（如
```
PRD.md
```
）、当前分支的近期提交记录、文件归属（如大型功能模块 vs 共享
```
lib/
```
目录）。
冲突代码块：合并期间使用
```
git show :2:path
```
（本地分支内容）对比
```
git show :3:path
```
（远程分支内容），或读取冲突标记；识别重复变更与正交变更。

将每个冲突区域分类为：

正交变更：可安全合并（如导入排序 + 新增属性）。
重叠变更：必须选择一方或手动合并（同一行内容冲突）。
损坏风险：重复代码块（错误合并后常见）；标记此类情况并建议从一方内容重建，再手动应用另一方的意图。

4. Recommendations + questions (required)

4. 给出建议并提问（必填）

Present to the user:

Summary table or bullets — file → recommended side or “manual merge” → one-line why.
Ordered by P0 → P3 — call out anything that removes a feature or changes public behavior first.
Explicit questions — anything ambiguous (e.g. “Keep main’s global behavior or the branch’s scoped variant?”).
Ask for direction — e.g. “Reply with: (a) follow recommendations, (b) keep branch for file X, (c) keep main for file Y, (d) abort merge.”

Only after the user confirms (or gives a precise mapping), apply resolutions:

Prefer small, surgical edits; preserve both sides’ intent when possible.
Re-run
```
git status
```
; ensure no conflict markers remain; run tests or lint the user cares about for touched areas.

向用户展示：

摘要表格或项目符号：文件 → 推荐选择的分支内容或 “手动合并” → 一行说明原因。
按P0→P3排序：首先标注任何会移除功能或变更公开行为的内容。
明确的问题：任何模棱两可的情况（如“保留main分支的全局行为还是当前分支的局部变体？”）。
请求用户指示：例如“请回复：(a) 遵循建议，(b) 保留当前分支的X文件内容，(c) 保留main分支的Y文件内容，(d) 终止合并。”

仅在用户确认（或给出明确映射）后，执行冲突解决：

优先进行小范围、精准的编辑；尽可能保留双方的意图。
重新执行
```
git status
```
；确保无冲突标记残留；对修改过的区域运行用户关注的测试或代码检查。

5. If the user wants to abort

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

```
git merge --abort
```
or
```
git rebase --abort
```
as appropriate; confirm they lose in-progress integration state for that operation.

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

Anti-patterns (do not do)

反模式（禁止操作）

Picking
```
--ours
```
/
```
--theirs
```
on the whole repo without user approval.
“Resolving” by deleting a feature branch’s work because main touched the same file.
Hiding conflict lists inside a long code dump without a short executive summary.
Fixing low-impact style conflicts first while leaving P0 decisions implicit.

未经用户批准，对整个仓库使用
```
--ours
```
/
```
--theirs
```
选项。
因main分支修改了同一文件，就删除功能分支上的工作内容来“解决”冲突。
将冲突列表隐藏在冗长的代码输出中，不提供简短的执行摘要。
先处理低影响的样式冲突，却将P0级别的决策隐含处理。

Quick reference

快速参考

Ours vs theirs (merge): stage 2 = current branch (
```
HEAD
```
), stage 3 = incoming (
```
MERGE_HEAD
```
). Verify with
```
git checkout --conflict=merge <file>
```
if needed.
Typical high-touch paths in full-stack or Dune apps: root app shell, top navigation, route modules, and shared
```
lib/
```
or
```
hooks/
```
.

For optional command snippets and a merge message template, see reference.md.

本地vs远程（合并场景）：stage 2 = 当前分支（
```
HEAD
```
），stage 3 = 传入分支（
```
MERGE_HEAD
```
）。如有需要，可使用
```
git checkout --conflict=merge <file>
```
验证。
全栈或Dune应用中典型的高冲突路径：根应用壳层、顶部导航、路由模块，以及共享的
```
lib/
```
或
```
hooks/
```
目录。

如需命令片段和合并消息模板，请查看reference.md。