pull

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pull

拉取操作

Workflow

工作流程

Verify git status is clean or commit/stash changes before merging.

Ensure rerere is enabled locally:

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

Confirm remotes and branches:
- Ensure the
```
origin
```
  remote exists.
- Ensure the current branch is the one to receive the merge.
Fetch latest refs:
- ```
git fetch origin
```
Sync the remote feature branch first:
- ```
git pull --ff-only origin $(git branch --show-current)
```
- This pulls branch updates made remotely (for example, a GitHub auto-commit) before merging
```
origin/main
```
  .

Merge in order:

Prefer

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

for clearer conflict context.

If conflicts appear, resolve them (see conflict guidance below), then:
- ```
git add <files>
```
- ```
git commit
```
  (or
```
git merge --continue
```
  if the merge is paused)
Verify with project checks (follow repo policy in
```
AGENTS.md
```
).
Summarize the merge:
- Call out the most challenging conflicts/files and how they were resolved.
- Note any assumptions or follow-ups.

合并前先验证git状态为干净，或者提交/暂存当前修改。

确保本地已启用rerere功能：

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

确认远程仓库和分支：
- 确保存在
```
origin
```
  远程仓库。
- 确保当前分支就是要接收合并内容的目标分支。
拉取最新引用：
- ```
git fetch origin
```
先同步远程功能分支：
- ```
git pull --ff-only origin $(git branch --show-current)
```
- 这一步会先拉取远程端对当前分支的更新（例如GitHub自动提交的内容），之后再合并
```
origin/main
```
  。
按顺序执行合并：
- 推荐使用
```
git -c merge.conflictstyle=zdiff3 merge origin/main
```
  以获得更清晰的冲突上下文。
如果出现冲突，先解决冲突（参考下方冲突解决指南），然后执行：
- ```
git add <files>
```
- ```
git commit
```
  （如果合并处于暂停状态，也可以执行
```
git merge --continue
```
  ）
执行项目检查进行验证（遵循
```
AGENTS.md
```
中约定的仓库规范）。
汇总合并情况：
- 标注最复杂的冲突/文件以及对应的解决方式。
- 记录所有假设内容或后续待办事项。

Conflict Resolution Guidance (Best Practices)

冲突解决指南（最佳实践）

Inspect context before editing:
- Use
```
git status
```
  to list conflicted files.
- Use
```
git diff
```
  or
```
git diff --merge
```
  to see conflict hunks.
- Use
```
git diff :1:path/to/file :2:path/to/file
```
  and
```
git diff :1:path/to/file :3:path/to/file
```
  to compare base vs ours/theirs for a file-level view of intent.
- With
```
merge.conflictstyle=zdiff3
```
  , conflict markers include:
  - ```
  <<<<<<<
```
  ours,
```
  |||||||
```
  base,
```
  =======
```
  split,
```
  >>>>>>>
```
  theirs.
- Matching lines near the start/end are trimmed out of the conflict region, so focus on the differing core.
- Summarize the intent of both changes, decide the semantically correct outcome, then edit:
  - State what each side is trying to achieve (bug fix, refactor, rename, behavior change).
  - Identify the shared goal, if any, and whether one side supersedes the other.
  - Decide the final behavior first; only then craft the code to match that decision.
  - Prefer preserving invariants, API contracts, and user-visible behavior unless the conflict clearly indicates a deliberate change.
- Open files and understand intent on both sides before choosing a resolution.
Prefer minimal, intention-preserving edits:
- Keep behavior consistent with the branch’s purpose.
- Avoid accidental deletions or silent behavior changes.
Resolve one file at a time and rerun tests after each logical batch.
Use
```
ours/theirs
```
only when you are certain one side should win entirely.
For complex conflicts, search for related files or definitions to align with the rest of the codebase.
For generated files, resolve non-generated conflicts first, then regenerate:
- Prefer resolving source files and handwritten logic before touching generated artifacts.
- Run the CLI/tooling command that produced the generated file to recreate it cleanly, then stage the regenerated output.
For import conflicts where intent is unclear, accept both sides first:
- Keep all candidate imports temporarily, finish the merge, then run lint/type checks to remove unused or incorrect imports safely.
After resolving, ensure no conflict markers remain:
- ```
git diff --check
```
When unsure, note assumptions and ask for confirmation before finalizing the merge.

编辑前先检查上下文：
- 使用
```
git status
```
  列出存在冲突的文件。
- 使用
```
git diff
```
  或
```
git diff --merge
```
  查看冲突块。
- 使用
```
git diff :1:path/to/file :2:path/to/file
```
  和
```
git diff :1:path/to/file :3:path/to/file
```
  分别比对基础版本与我方/对方版本，从文件级别了解修改意图。
- 当
```
merge.conflictstyle=zdiff3
```
  配置生效时，冲突标记包含：
  - ```
  <<<<<<<
```
  我方修改，
```
  |||||||
```
  基础版本，
```
  =======
```
  分割线，
```
  >>>>>>>
```
  对方修改。
- 冲突区域首尾附近的相同行会被省略，因此请重点关注存在差异的核心内容。
- 总结两边修改的意图，确定语义正确的合并结果后再进行编辑：
  - 明确两边修改各自要实现的目标（bug修复、重构、重命名、行为变更）。
  - 识别是否存在共同目标，以及是否其中一方的修改完全覆盖另一方。
  - 先确定最终要实现的行为，再编写对应匹配的代码。
  - 除非冲突明确表明需要做刻意变更，否则优先保留不变量、API契约以及用户可感知的行为。
- 打开文件，理解两边的修改意图后再选择解决方案。
优先选择最小化、保留修改意图的编辑方式：
- 保持行为与分支的设计目标一致。
- 避免意外删除内容或静默修改行为。
每次解决一个文件的冲突，每完成一批逻辑相关的冲突解决后重新运行测试。
仅当你完全确定其中一方的修改应该完全覆盖另一方时，才使用
```
ours/theirs
```
策略。
针对复杂冲突，可以搜索相关文件或定义，确保修改与代码库其余部分保持一致。
针对生成的文件，先解决非生成内容的冲突，再重新生成文件：
- 优先解决源文件和手写逻辑的冲突，再处理生成的产物。
- 运行生成该文件对应的CLI/工具命令，重新生成干净的文件，然后暂存重新生成的输出。
针对意图不明确的导入冲突，先同时保留两边的内容：
- 临时保留所有候选导入，完成合并后运行lint/类型检查，安全移除未使用或不正确的导入。
解决完冲突后，确保没有残留的冲突标记：
- ```
git diff --check
```
如有不确定，记录下假设内容，在最终完成合并前请求确认。

When To Ask The User (Keep To A Minimum)

何时需要询问用户（尽量少问）

Do not ask for input unless there is no safe, reversible alternative. Prefer making a best-effort decision, documenting the rationale, and proceeding.

Ask the user only when:

The correct resolution depends on product intent or behavior not inferable from code, tests, or nearby documentation.
The conflict crosses a user-visible contract, API surface, or migration where choosing incorrectly could break external consumers.
A conflict requires selecting between two mutually exclusive designs with equivalent technical merit and no clear local signal.
The merge introduces data loss, schema changes, or irreversible side effects without an obvious safe default.
The branch is not the intended target, or the remote/branch names do not exist and cannot be determined locally.

Otherwise, proceed with the merge, explain the decision briefly in notes, and leave a clear, reviewable commit history.

除非没有安全、可回滚的替代方案，否则不要请求用户输入。优先尽最大努力做出决策，记录决策理由后继续推进。

仅在以下场景下询问用户：

正确的解决方案取决于无法从代码、测试或周边文档推断出的产品意图或行为。
冲突涉及用户可感知的契约、API对外暴露面或者迁移逻辑，选择错误可能会破坏外部依赖方的使用。
冲突需要在两个技术价值相当、且没有明确本地信号支撑选择的互斥设计之间做抉择。
合并会引入数据丢失、schema变更或者不可逆的副作用，且没有明确的安全默认选项。
分支不是预期的合并目标，或者远程/分支名称不存在且无法在本地确定。