pull

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pull

拉取同步

Purpose

用途

Bring the current branch up to date with the remote default branch (typically
```
origin/main
```
) using a merge (not rebase, unless AGENTS.md or team policy says otherwise).
Resolve merge conflicts safely and verify with pnpm lint && pnpm test
(or the repo’s documented checks).
Prefer rerere and clear conflict styles so repeated conflicts are easier to handle.

使用合并（而非变基，除非AGENTS.md或团队政策另有规定）的方式，让当前分支与远程默认分支（通常为
```
origin/main
```
）保持同步。
安全解决合并冲突，并通过**
```
pnpm lint && pnpm test
```
**（或仓库文档中规定的检查项）进行验证。
优先使用rerere工具和清晰的冲突标记格式，以便更轻松地处理重复出现的冲突。

Prerequisites

前置条件

Git remote
```
origin
```
exists and points at the expected host.
You know which branch is the integration base (usually
```
main
```
; use the repo’s default if different).

Git远程仓库
```
origin
```
已存在，且指向预期的托管平台。
你已明确集成基准分支（通常为
```
main
```
；若仓库使用其他默认分支，则以仓库设置为准）。

When to Use

适用场景

"pullして", "main を取り込んで", "同期して", or similar—when the feature branch must match
```
origin/main
```
(or the team base branch).
After git push
is rejected with non-fast-forward, or when the local branch is behind the remote tracking branch.
When preparing to push and the branch needs the latest upstream changes first (often chained before push).

当需求为「pullして」「main を取り込んで」「同期して」或类似表述时——即功能分支必须与
```
origin/main
```
（或团队基准分支）保持一致的场景。
在**
```
git push
```
因非快进问题被拒绝后，或本地分支落后于远程跟踪分支**时。
准备推送分支前，需要先获取上游最新变更的场景（通常会在push操作前执行本操作）。

Do Not Use When

不适用场景

The user only wants to push without merging the base (use push; if push fails, then use pull).
The user wants to create or update a GitHub PR (use create-pr-jp).
The goal is merging or landing an approved PR on the default branch (use a land or merge workflow skill if the workspace defines one—not this skill).

用户仅需推送分支而无需合并基准分支时（使用push操作；若推送失败，再使用本操作）。
用户需要创建或更新GitHub PR时（使用create-pr-jp操作）。
目标是在默认分支上合并或落地已批准的PR时（若工作区定义了相关的「land」或合并工作流技能，请使用该技能——而非本操作）。

Related Skills

Procedure

操作步骤

Ensure the working tree is safe to merge: commit or stash uncommitted work before merging.

Enable rerere locally (recommended):

```
git config rerere.enabled true
```
```
git config rerere.autoupdate true
```

Confirm remotes and branch:
```
origin
```
exists; the current branch is the one that should receive the merge.
Fetch:
```
git fetch origin
```
Fast-forward the current branch from its remote counterpart if it exists (picks up remote-only commits before merging main):
- ```
git pull --ff-only origin "$(git branch --show-current)"
```
Merge the base branch (replace
```
main
```
if the repo uses another default):
- Prefer
```
git -c merge.conflictstyle=zdiff3 merge origin/main
```
  for clearer conflict context.
If conflicts appear, resolve them (see Conflict Resolution below), then:
- ```
git add <files>
```
- ```
git commit
```
  or
```
git merge --continue
```
  as appropriate.
Verify: run pnpm lint && pnpm test
, or follow
```
AGENTS.md
```
/ project scripts if they differ.
Summarize for the user: hardest conflicts, how they were resolved, and any follow-ups.

确保工作区状态适合合并：合并前提交或暂存所有未提交的工作。

本地启用rerere工具（推荐）：

```
git config rerere.enabled true
```
```
git config rerere.autoupdate true
```

确认远程仓库和分支：
```
origin
```
已存在；当前分支为需要合并基准分支的目标分支。
拉取远程变更：
```
git fetch origin
```
如果当前分支存在远程跟踪分支，先进行快进同步（在合并main分支前，获取仅存在于远程的提交）：
- ```
git pull --ff-only origin "$(git branch --show-current)"
```
合并基准分支（若仓库使用其他默认分支，替换
```
main
```
即可）：
- 优先使用
```
git -c merge.conflictstyle=zdiff3 merge origin/main
```
  命令，以获得更清晰的冲突上下文。
若出现冲突，按照下方冲突解决部分的步骤处理，然后：
- ```
git add <files>
```
- 根据情况执行
```
git commit
```
  或
```
git merge --continue
```
  。
验证：运行**
```
pnpm lint && pnpm test
```
**，若仓库有自定义检查脚本，则遵循AGENTS.md或项目脚本的要求。
向用户总结：说明最难处理的冲突、解决方式，以及后续需要执行的操作。

Output

输出结果

Current branch contains the merged base; conflicts resolved; pnpm lint && pnpm test
(or repo equivalent) passed.
A clear narrative of what was merged and any notable resolution decisions.

当前分支已合并基准分支的内容；冲突已解决；pnpm lint && pnpm test
（或仓库等效检查）已通过。
清晰说明合并的内容，以及任何值得注意的冲突解决决策。

Usage

使用示例

Reference flow (adapt

main

/ branch names to the repo):

git config rerere.enabled true
git config rerere.autoupdate true

git fetch origin

参考流程（根据仓库情况调整

main

或分支名称）：

git config rerere.enabled true
git config rerere.autoupdate true

git fetch origin

Optional: sync remote feature branch commits first

可选：先同步远程功能分支的提交

git pull --ff-only origin "$(git branch --show-current)"

Merge default branch (zdiff3 for conflict readability)

合并默认分支（使用zdiff3格式提升冲突可读性）

git -c merge.conflictstyle=zdiff3 merge origin/main

After resolving conflicts:

解决冲突后：

git add … && git commit # or git merge --continue

git add … && git commit # 或执行 git merge --continue

pnpm lint && pnpm test

undefined

pnpm lint && pnpm test

undefined

Conflict Resolution

冲突解决

Inspect before editing:
- ```
git status
```
  for conflicted files;
```
git diff
```
  /
```
git diff --merge
```
  for hunks.
- Optional:
```
git diff :1:path :2:path
```
  and
```
:1:
```
  vs
```
:3:
```
  for base vs ours/theirs.
- With
```
merge.conflictstyle=zdiff3
```
  , markers are
```
<<<<<<<
```
  ours,
```
|||||||
```
  base,
```
=======
```
  ,
```
>>>>>>>
```
  theirs.
- Infer intent on both sides; choose semantics first, then edit code.
Prefer minimal, intention-preserving edits aligned with the branch’s purpose.
Resolve in batches; rerun
pnpm lint && pnpm test
after a logical batch of files when helpful.
Use ours/theirs only when one side should win entirely.
Generated files: fix sources first, then regenerate with the project’s command; stage regenerated output.
Import conflicts: if unclear, temporarily keep both imports, finish the merge, then let lint/typecheck trim unused imports.
After resolution:
```
git diff --check
```
(no conflict markers left).

编辑前先检查：
- 使用
```
git status
```
  查看存在冲突的文件；使用
```
git diff
```
  /
```
git diff --merge
```
  查看冲突片段。
- 可选：使用
```
git diff :1:path :2:path
```
  和
```
:1:
```
  vs
```
:3:
```
  对比基准版本与我方/对方版本。
- 若设置了
```
merge.conflictstyle=zdiff3
```
  ，冲突标记格式为
```
<<<<<<<
```
  我方代码、
```
|||||||
```
  基准代码、
```
=======
```
  、
```
>>>>>>>
```
  对方代码。
- 推断双方代码的意图；优先保证语义正确，再编辑代码。
优先选择最小化、保留意图的修改，且符合分支的用途。
分批解决冲突；必要时，在完成一批逻辑相关的文件冲突解决后，重新运行
pnpm lint && pnpm test
。
仅当某一方的代码应完全保留时，才使用ours/theirs策略。
生成文件：先修复源文件，再使用项目命令重新生成文件；将重新生成的输出文件加入暂存区。
导入冲突：若无法明确处理，可暂时保留两个导入，完成合并后，通过lint/类型检查工具移除未使用的导入。
解决冲突后：执行
```
git diff --check
```
（确保无残留的冲突标记）。

When to Ask the User

需咨询用户的场景

Ask only when there is no safe default. Prefer a documented decision and proceed otherwise.

Ask when:

Product behavior cannot be inferred from code, tests, or docs.
The conflict affects a public API, migration, or contract with no clear safe choice.
Two designs are equally plausible with no local signal.
The change risks data loss, schema damage, or irreversible effects without a safe default.
The branch or remote names cannot be determined locally.

Otherwise complete the merge, note assumptions briefly, and leave reviewable history.

仅在没有安全默认方案时才咨询用户。否则优先按照文档规定的决策执行。

以下场景需咨询用户：

无法从代码、测试或文档中推断产品行为时。
冲突影响公共API、迁移或契约，且没有明确的安全选择时。
两种实现方案同样合理，且本地无参考依据时。
修改可能导致数据丢失、 schema损坏或不可逆影响，且无安全默认方案时。
无法在本地确定分支或远程仓库名称时。

其他场景下，完成合并操作，简要记录假设，并留下可审查的提交历史。

Present Results to User

向用户展示结果

State the base branch merged (e.g.
```
origin/main
```
) and the current branch name.
List major conflict areas and how they were fixed.
Report pnpm lint && pnpm test
(or what ran) and pass/fail.
Do not claim a PR was updated or that commits were pushed—those are create-pr-jp and push.

说明合并的基准分支（例如
```
origin/main
```
）和当前分支名称。
列出主要的冲突区域及解决方式。
报告**
```
pnpm lint && pnpm test
```
**（或实际运行的检查命令）的执行结果（通过/失败）。
切勿声称已更新PR或推送提交——这些操作属于create-pr-jp和push的功能范围。

Notes

注意事项

Default integration strategy here is merge; do not rebase unless the repository explicitly requires it.
If
```
git pull --ff-only origin <branch>
```
fails, diagnose (diverged history) before merging
```
origin/main
```
.

本操作默认的集成策略为合并；除非仓库明确要求，否则不要使用变基。
若
```
git pull --ff-only origin <branch>
```
执行失败，需先诊断问题（历史分歧），再合并
```
origin/main
```
。

Troubleshooting

故障排除

Situation	Action
Dirty working tree	Commit or stash before merge
`merge` conflicts	Follow Conflict Resolution, then `pnpm lint && pnpm test`
Wrong default branch name	Use `git symbolic-ref refs/remotes/origin/HEAD` or repo docs for `main` vs `master`
Lint/test fails after merge	Fix or revert; do not push broken state—coordinate with push only after green checks

场景	操作
工作区未提交变更	合并前提交或暂存变更
出现 `merge` 冲突	按照冲突解决步骤处理，然后执行 `pnpm lint && pnpm test`
默认分支名称错误	使用 `git symbolic-ref refs/remotes/origin/HEAD` 命令或查看仓库文档，确认是 `main` 还是 `master`
合并后lint/test失败	修复问题或回滚；不要推送存在问题的状态——只有检查通过后，再配合push操作进行推送