是否可以将修补程序分支合并到 Github 中的开发和主分支？

Question

我现在使用gitflow策略和github作为远程仓库。

最近遇到了将hotfix PR合并到develop和main分支的问题

Github 似乎只支持一个 PR 的目标分支，并且不知道分支是功能还是修复。

目前我只是关闭 PR 并在本地合并它们并推送到远程。

有没有人有好主意或 github 功能我可以用来将修补程序分支同时合并到开发和主分支？

提前致谢。

Answer 1

总的来说，将同一个PR同时合并到多个分支是一个非常糟糕的主意。

唯一的例外是将其中一个 PR 标记为具有一些

do-not-merge

标签的草稿 - 为了触发 CI 对更改的传递。

---

这有两个主要问题：

不一致的历史

同时将同一组更改合并到多个分支中——而不是按顺序进行，即。首先登陆一个分支 - 创建两个不相互链接的不同提交。

这让人们更难弄清楚特定的修复是否进入了特定的分支。

在出现严重错误并且需要恢复修复的极少数情况下更是如此。

拆分代码审查

如果你在一个更大的组织中进行同行代码审查，那么审查 - 和评论/问题 - 可能会在两个 PR 之间分开。

你甚至可能会浪费其他人的时间，例如，如果你的一个 PR 在处理了一些评论后获得了批准——而另一个没有看到该评论的人评论了另一个版本。

---

所以最好先将您的更改放在一个分支中——通常是您的开发分支——然后创建一个 PR 将这些已经合并的更改合并到另一个分支中。

你这样做的方式是先将你的 PR 合并到开发分支中。

然后，从当前主分支创建一个集成分支，

git cherry-pick

将您的更改合并到开发分支的提交（您可能想使用

git cherry-pick -x

并可能编辑提交消息以包含指向该合并 PR 的链接），然后创建一个 PR，并在描述中包含指向上一个 PR 的链接。

这是一些额外的工作，对于小型项目来说并不是真正需要的，但是一旦您的项目增长，它将变得非常重要。

Answer 2

请注意，一个 PR = 一个合并。您只需要两个单独的 PR，一个将

hotfix

合并到

main

，另一个将

hotfix

合并到

develop

。关于代码审查，Git Flow Hotfix 分支 最好也是受保护的分支，它本身需要代码审查。例如：

1. 当你意识到你需要一个修补程序时，你创建一个

   main

   的分支，例如

   hotfix-1.2.3

   （或

   hotfix/1.2.3

   ）。保护分支，以便需要 PR 合并到其中，就像

   develop

   和

   main

   .
2. 使用普通的 PR 将带有修补程序提交的功能分支合并到

   hotfix

   分支中。
3. 测试

   hotfix

   分支。
4. 部署修补程序，并将

   hotfix

   合并到

   main

   和

   develop

   中。这 2 次合并是“Git Flow”合并，可以自动化并绕过 PR 过程。或者您可以为这两个合并设置 2 个以上的 PR。请注意，这 2 个 PR 不需要像步骤 #2 中的 PR 那样进行定期代码审查。由于这些 PR could 是自动化的，如果你需要一个人来批准，他们可能只是做一个快速的完整性检查以确保合并是正确的。

关于：

目前我只是关闭 PR 并在本地合并它们并推送到远程。

这样做会奏效，并且与第 4 步中描述的自动化 2 次合并有点类似。如果你走那条路，我建议你编写脚本，这样它就可以重复并且不容易出错。请注意，当您有合并冲突时，您将需要手动干预。

提示： 在使用 Git Flow 时，我个人的偏好是在完成

release

和

hotfix

分支时，先将它们合并到

main

，然后再将

main

合并到

develop

（而不是同时合并发布或修补程序分支到

develop

）。这样做在功能上是等价的，除了

main

上的合并提交会立即降级为

develop

，而不是下一个

hotfix

。这种方式稍微干净一点，这也意味着

develop

和/或您的

release

分支始终与

main

完全同步，在state和commits中。 （按照 Git Flow 记录的方式进行操作只会使 state 保持最新。）