如何使用 GitHub 拉取请求进行修补程序

Question

警告：我对 git 和 GitHub 都很陌生。

因此，在我当前的设置中，我的团队使用 git flow Hotfixes（通常由 GitKraken 或 IntelliJ 等图形工具启动和完成）进行更改，这些更改必须合并到两个分支中并在两个分支中推送到上游。例如，流程将是：

1. 从 master 拉最新的
2. 启动修补程序
3. 提交更改
4. 将修补程序分支合并到 master 和 development 并推送到上游

我们现在正在考虑将我们的代码移至 GitHub 并希望开始使用 Pull Requests，原因如下：

• 用于运行测试和东西的 CI 挂钩
• 放置与底层“问题”不直接相关的特定于代码的 cmets 的地方
• 避免每个人都需要不断将最新的主/开发人员拉到他们的本地计算机上，以便他们可以合并更改

但是对于修补程序，我不确定该怎么做，因为我正在合并到两个分支中，但它确实是一个“操作”，因此手动创建两个拉取请求似乎很奇怪，特别是在我们的步骤 4) 之后只需单击一下即可获得当前流量。

有没有聪明的方法来处理这个问题？我的理想情况是，按下 Pull Request 上的 Merge 按钮只会合并到两者中，但这似乎不是一个可用的选项。

Answer 1

正如您所提到的，拉取请求只有 一个 目标分支，因此您无法通过合并一个拉取请求将修补程序推送到 master 和 develop。

我也很惊讶你提到你的步骤 #4 - 将修补程序分支合并到 master 和 develop 并推送到上游 - 是一个动作。虽然从hotfix 到master 的合并很有可能不会遇到合并冲突，但我不能对从hotfix 到develop 的合并说同样的话，因为它本可以从上次部署到生产环境。

我的建议如下：

• 创建一个从 hotfix 到 master 的 PR，并让某人对其进行审核以验证修复
• 一旦它被合并到master，创建另一个从hotfix到develop的PR，看看你是否遇到合并冲突
  • 如果是这种情况，请解决合并冲突，使 PR 最终处于要合并的状态，并让某人审核 PR
  • 如果没有合并冲突，则请人审核 PR

---

如果您真的想走自动化路径，另一种解决方案是同时利用 GitHub Webhook 和 API。

Webhook 将允许您成为 notified when a PR is merged。您可以检查有效负载以确保基本分支以hotfix/ 开头，而目标分支是master。然后，您可以使用从同一 hotfix 分支到 develop 的 API 对 create a new PR 做出反应。

这将涉及一些开发，并且可能不值得付出努力，因为通过 UI 创建 PR 仍然非常简单快捷。

Answer 2

我今天遇到了这个问题，如果一个人想避免合并以保持干净的历史记录，那么选择的解决方案就不起作用，因为 develop 将与 master 分离并需要合并提交。

就我而言，我针对生产（主）提出了拉取请求，然后将生产（主）重新定位为集成（开发）。