如何在本地测试 GitHub 合并冲突

Source: Dev.to

请提供您希望翻译的完整文本内容（除代码块、URL 和源链接外），我将把它翻译成简体中文并保持原有的 Markdown 格式。谢谢！

实际重要的简短工作流

对于这种测试，我关注的是一个非常小的流程：

1. 打开 Pull Request
2. 再次获取该 PR 以检查其状态
3. 尝试合并步骤
4. 查看当 PR 无法干净合并时，你的系统会怎么表现

这可以从类似下面的操作开始：

curl -X POST \
  "https://api.github.com/repos/acme-corp/api-gateway/pulls" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  -d '{
    "title": "fix: handle nil pointer in rate limiter",
    "body": "Fixes #142. Adds nil check before accessing connection pool.",
    "head": "fix/rate-limiter-nil",
    "base": "main"
  }'

随后很快会变成：

curl \
  "https://api.github.com/repos/acme-corp/api-gateway/pulls/" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json"

关键不只是 PR 已经存在，而是当分支无法干净合并时，你的代码会如何处理。

团队常常被误导的地方

将 “pull request created” 当作自动化基本完成的证明是一种陷阱。许多 GitHub 工作流只有在创建之后才变得有意义：

• 分支已过时（main 上已经合并了其他更改）。
• PR 看起来有效，但实际上不可合并。
• 你的机器人仍然尝试继续执行。
• 你的 UI 显示 “ready”，即使此时需要人工介入。

这与许多异步集成中出现的相同模式相吻合：第 1 步成功后，应用就假设整个任务都是健康的。

我在投产前会测试的内容

如果我只能抽出时间做一次针对 GitHub API 的狭窄测试，我会测试 merge‑conflict 分支。我会检查：

• 我的应用能否检测到 PR 已存在但无法安全合并？
• 我是否向用户展示了正确的状态，而不是假装它仍然是普通的合并路径？
• 重试时是否一直在同一个 PR 上敲击，还是会停止并明确地呈现冲突？
• 如果流程中还有 webhook 或后续读取，最终状态是否保持真实？

最后一点比第一次 API 调用更重要。许多自动化错误并不是 “无法创建 PR”。它们更像是：

• “我们已经创建了 PR，但随后误读了后续状态。”
• “我们重试了错误的步骤。”
• “我们太晚告诉用户合并被阻止了。”

为什么这比另一个 PR 正常路径的测试更好

一个正常路径的拉取请求测试主要证明你能与 GitHub 通信。合并冲突测试则告诉你你的集成是否能在仓库状态不断变化的情况下生存。这对以下情况提供了更好的信号：

• 发布工具
• 打开 PR 的 AI 编码代理
• 尝试自动合并修复的内部自动化
• 任何假设分支状态在创建到合并之间保持干净的工作流

它也更贴近实际。真实的仓库会不断漂移。如果你的测试从未触及冲突分支，你的合并逻辑可能被高估了。

我认为被低估的部分

有用的问题不仅仅是：

“我能通过 GitHub API 创建 PR 吗？”

而是：

“当 PR 不再可合并时，我还能知道发生了什么以及接下来该怎么做吗？”

这就是端点测试与工作流测试之间的差距。端点文档解释了请求的结构。真正的集成工作是决定在分支状态变化后你的系统应该怎么做。

如果想在本地让这件事更简单

我更喜欢把它当作一个狭窄的工作流来测试，而不是一个宽泛的 “GitHub API 集成” 检查。这也是我在 FetchSandbox 上保留可运行的 GitHub 文档门户 的原因。这样做的好处是可以在同一个地方打开 PR、再次获取它，并检查后续分支，而不是在创建时就停下来。

对我而言，合并冲突的路径正是那种通过一次小的失败模式测试能学到的东西，胜过一次冗长的成功路径演示。

想了解其他人是怎么处理的。如果你的 GitHub 自动化在打开 PR 后遇到冲突，你会把它作为一个一等状态展示出来，还是仍然会导致日志深挖和困惑的重试？