pull

拉取

工作流

1. 确认 Git 状态干净，或在合并前提交／暂存更改。
2. 确保本地已启用 rerere：
   • git config rerere.enabled true
   • git config rerere.autoupdate true
3. 确认远程仓库和分支：
   • 确保存在 origin 远程仓库。
   • 确保当前分支是要接收合并的分支。
4. 获取最新的引用：
   • git fetch origin
5. 先同步远程功能分支：
   • git pull --ff-only origin $(git branch --show-current)
   • 这会在合并 origin/main 之前拉取远程所做的分支更新（例如 GitHub 自动提交）。
6. 按顺序合并：
   • 建议使用 git -c merge.conflictstyle=zdiff3 merge origin/main，以便更清晰地查看冲突上下文。
7. 如果出现冲突，请解决冲突（参见下方的冲突处理指南），然后：
   • git add <files>
   • git commit（如果合并处于暂停状态，则使用 git merge --continue）
8. 按照项目检查要求进行验证（遵循 AGENTS.md 中的仓库策略）。
9. 总结合并情况：
   • 指出最棘手的冲突／文件，以及解决方式。
   • 说明任何假设或后续事项。

冲突处理指南（最佳实践）

• 编辑前先检查上下文：
  • 使用 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 时，冲突标记包括：
    • <<<<<<< 我方，||||||| 基础版本，======= 分隔符，>>>>>>> 对方。
    • 冲突区域开头／结尾附近的匹配行会被省略，因此请重点关注存在差异的核心内容。
  • 总结双方更改的意图，判断语义上正确的处理结果，然后再编辑：
    • 说明每一方想实现什么（错误修复、重构、重命名、行为更改）。
    • 找出双方是否有共同目标，以及一方是否取代了另一方。
    • 先确定最终行为，再编写与该决定一致的代码。
    • 除非冲突明确表明需要有意更改，否则优先保留不变量、API 契约和用户可见行为。
  • 在选择解决方案之前，先打开文件并理解双方的意图。
• 优先进行最小限度且保留原意的编辑：
  • 保持行为与分支的用途一致。
  • 避免意外删除或悄无声息地改变行为。
• 一次解决一个文件，并在每个逻辑批次后重新运行测试。
• 只有确定应完全采用某一方的更改时，才使用 ours/theirs。
• 对于复杂冲突，请搜索相关文件或定义，确保与代码库的其他部分保持一致。
• 对于生成文件，先解决非生成文件的冲突，再重新生成：
  • 优先处理源文件和手写逻辑，再处理生成产物。
  • 运行生成该文件的 CLI／工具命令，以干净地重新生成文件，然后暂存重新生成的输出。
• 对于意图不明确的导入冲突，先接受双方的更改：
  • 暂时保留所有候选导入，完成合并，然后运行 lint／类型检查，安全地移除未使用或不正确的导入。
• 解决冲突后，确保没有残留冲突标记：
  • git diff --check
• 不确定时，记录假设，并在最终完成合并前请求确认。

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

除非没有安全且可逆的替代方案，否则不要向用户征求意见。优先尽力做出决策，记录理由并继续。

仅在以下情况下询问用户：

• 正确的解决方案取决于代码、测试或附近文档无法推断的产品意图或行为。
• 冲突涉及面向用户的契约、API 接口或迁移，错误选择可能会破坏外部使用者。
• 冲突要求在两个技术价值相当、且没有明确本地依据的互斥设计之间做出选择。
• 合并会导致数据丢失、架构变更或不可逆副作用，且没有明显安全的默认方案。
• 当前分支不是预期目标分支，或者远程仓库／分支名称不存在且无法在本地确定。

否则，继续合并，在备注中简要说明决策，并保留清晰、便于审查的提交历史。