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)
```
- 这会在合并
```
origin/main
```
  之前，拉取远程对该分支的更新（例如GitHub自动提交）。
按顺序合并：
- 优先使用
```
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变更或不可逆的副作用，且没有明显的安全默认选项。
分支不是预期的目标，或远程/分支名称不存在且无法在本地确定。

否则，继续执行合并，在注释中简要解释决策，并留下清晰、可审查的提交历史。