如何使用GitHub Pull Requests做修补程序

Dan*_*Dan 30 github git-flow

警告:我对git和GitHub都很新.

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

  1. 从大师拉最新
  2. 启动修补程序
  3. 提交更改
  4. 将修补程序分支合并到主服务器中并开发并推送上游两者

我们现在正在考虑将代码移到GitHub中,并希望开始使用Pull Requests,原因如下:

  • CI挂钩运行测试和东西
  • 放置代码特定注释的地方与底层"问题"没有直接关系
  • 避免每个人不断地将最新的master/develop拉到他们的本地机器上,以便他们可以合并更改

但在Hotfixes的情况下,我不知道该怎么办,因为我正在合并到两个分支但它真的是一个"动作"所以手动创建两个拉动请求似乎很奇怪,特别是因为我们当前的流程中的步骤4)单击一下.

有一种聪明的方法来处理这个问题吗?我理想的情况是推动Pull Request上的Merge按钮只会合并到两者中,但这似乎不是一个可用的选项.

Mic*_*iey 27

正如您所提到的,Pull Request只有一个目标分支,因此您无法将修补程序推送到两者masterdevelop合并一个Pull Request.

我也很惊讶你提到你的步骤#4 - 将修补程序分支合并到两者master并且develop向上游推送 - 是一个动作.虽然有一个高的机会从合并hotfixmaster不会遇到合并冲突,我不能说,从用于合并同hotfixdevelop,因为它可能已自上次部署到生产制作.

我的建议如下:

  • 从创建一个PR hotfixmaster,并有专人进行审查,以确认修复
  • 一旦它合并到master,从创建另一个PR hotfixdevelop,看看你是否遇到合并冲突
    • 如果是这种情况,请解决合并冲突,以便PR最终处于要合并的状态,并让某人审核PR
    • 如果没有合并冲突,那么让某人审查PR

如果您真的想要沿着自动化路径走下去,另一种解决方案是利用GitHub webhooks和API.

webhook将允许您在合并PR时收到通知.您可以检查有效负载以确保基本分支hotfix/以及目标分支开头master.然后,您可以通过使用API 从同一分支创建新PR来对该事件做出反应.hotfixdevelop

它将涉及一些开发,并且努力可能不值得,因为通过UI创建PR仍然非常容易和快速.