英文:
Is it possible to merge hotfix branch to both develop and main branch in Github?
问题
我现在正在使用gitflow策略和GitHub作为远程仓库。
最近，我遇到了将热修复分支合并到develop和main分支的问题。
似乎GitHub只支持将PR合并到一个目标分支，并不知道一个分支是特性分支还是热修复分支。
目前，我只是关闭PR，然后在本地合并它们，然后推送到远程。
有没有人有好的想法或GitHub功能，我可以使用它来同时将热修复分支合并到develop和main分支？
提前感谢。
英文:
I'm now using gitflow strategy and github as a remote repository.
Recently I encountered a problem of merging hotfix PRs into both develop and main branch.
It seems the Github supports only one target branch for a PR and doesn't know whether a branch is feature or hotfix.
Currently, I just close PR and merge them in local and push it to the remote.
Is anybody have nice idea or github feature I can use to merge a hotfix branch to both develop and main branch at the same time?
Thanks in advance.
答案1
得分: 2
请注意，一个PR等于一个合并操作。您只需要创建两个单独的PR，一个用于将hotfix合并到main，另一个用于将hotfix合并到develop。关于代码审查，最好将Git Flow Hotfix分支设置为受保护分支，这本身需要进行代码审查。例如：
- 当您意识到需要一个热修复时，可以从
main创建一个分支，例如hotfix-1.2.3（或hotfix/1.2.3）。保护该分支，以便需要PR才能合并，就像develop和main一样。 - 使用普通的PR将功能分支与热修复提交合并到
hotfix分支。 - 测试
hotfix分支。 - 部署热修复，并将
hotfix合并到main和develop。这两个合并操作是"Git Flow"合并，可能可以自动化执行并绕过PR流程。或者您可以为这两个合并创建2个额外的PR。请注意，这两个PR不需要像步骤#2中的PR那样进行常规代码审查。由于这些PR可能可以自动化执行，如果您需要人工批准，他们可能只需要快速检查合并是否正确即可。
关于：
>目前，我只是关闭PR并在本地合并它们，然后推送到远程。
这种方法也可以，与步骤#4中描述的自动化合并几乎相同。如果您选择这种方法，我建议编写脚本以使其可重复执行并减少错误的机会。请注意，当存在合并冲突时，您仍然需要手动干预。
**提示：**在使用Git Flow时，我个人更喜欢在完成release和hotfix分支时首先将它们合并到main，然后将main合并到develop（而不是将发布或热修复分支合并到develop）。这样做在功能上是等效的，只是将在main上生成的合并提交立即传递到develop，而不是等到下一个hotfix。这种方式略微更加清晰，而且意味着develop和/或您的release分支在状态和提交方面始终与main完全保持同步。（按照Git Flow文档的方式只会使状态保持同步。）
英文:
Note that One PR = One merge. All you need are two separate PRs, one to merge hotfix into main, and another to merge hotfix into develop. Regarding the code reviews, it's best for a Git Flow Hotfix branch to also be a protected branch, which itself requires a code review. For example:
- When you realize you need a hotfix, you create a branch off of
main, for examplehotfix-1.2.3(orhotfix/1.2.3). Protect the branch so that PRs are required to merge into it, just like fordevelopandmain. - Use a normal PR to merge a feature branch with the hotfix commit(s) into the
hotfixbranch. - Test the
hotfixbranch. - Deploy the hotfix, and merge
hotfixintomainand also intodevelop. These 2 merges are "Git Flow" merges and can possibly be automated and bypass the PR process. Or you can create 2 more PRs for the two merges. Note that these 2 PRs do not require regular code reviews like the PR in step #2. Since these PRs could be automated, if you need a human to approve, they can likely just do a quick sanity check that the merges are correct.
Regarding:
> Currently, I just close PR and merge them in local and push it to the remote.
Doing that will work, and is kind of the same thing as automating the 2 merges as described in step #4. If you go that route I would recommend scripting it so that it's repeatable and less prone to error. Note that when you have merge conflicts, you will need to manually intervene regardless.
Tip: When using Git Flow, my personal preference when completing both release and hotfix branches, is to first merge them into main, and then merge main into develop (instead of also merging the release or hotfix branch into develop). Doing this is functionally equivalent, except that the merge commit that goes on main gets brought down to develop immediately, instead of with the next hotfix. It's slightly cleaner this way and it also means that develop and/or your release branches are always fully up to date with main, in both state and commits. (Doing it the way Git Flow is documented only brings the state up to date.)
答案2
得分: 0
以下是翻译好的部分：
一般来说，同时将相同的PR合并到多个分支是一个非常不好的主意。
唯一的例外是将其中一个PR标记为草稿，并添加一些 do-not-merge 标签 - 以触发对更改的CI检查。
这样做有两个主要问题：
不一致的历史记录
同时将相同的一组更改合并到多个分支而不是按顺序进行合并，即首先合并到一个分支 - 会创建两个不相互关联的不同提交。
这使得人们更难以确定特定修复是否进入了特定分支。
在极少数情况下，如果出现严重问题需要回滚修复，情况会更加复杂。
代码审查分离
如果你在一个较大的组织中进行同行代码审查，有可能审查 - 以及评论/问题 - 会分散在两个PR之间。
甚至可能浪费其他人的时间，例如在你的一个PR经过一些评论后获得批准，然后另一个人在没有看到审查的情况下审查了另一个版本。
因此，更好的方法是首先将你的更改合并到一个分支中 - 通常是你的开发分支 - 然后创建一个PR，将这些已合并的更改合并到另一个分支中。
你可以通过首先将你的PR合并到开发分支中来实现这一点。
然后，从当前主分支创建一个集成分支，使用 git cherry-pick 命令挑选将你的更改合并到开发分支的提交（你可能想要使用 git cherry-pick -x 并可能编辑提交消息以包含指向已合并PR的链接），然后创建一个PR并在描述中包含对先前PR的链接。
这需要一些额外的工作，对于小型项目来说可能并不是真正需要的，但一旦你的项目变大，这将变得非常重要。
英文:
In general, merging the same PR into multiple branches at the same time is a very bad idea.
The only exception is marking one of the PR's as a Draft with some do-not-merge tag - in order to trigger a CI pass on the changes.
There are two major issues with this:
Inconsistent History
Merging the same set of changes into multiple branches at the same time - instead of doing it sequentially, ie. landing in one branch first - creates two distinct commits that are not linked to one another.
This makes it a lot harder for people to figure out whether a particular fix went into a particular branch.
Even more so in the rare case that something went terribly wrong and the fix needs to be reverted.
Split Code Review
If you're in a bigger organization that does peer code review, chances are that reviews - and comments / questions - could get split between the two PR's.
You might even waste other people's time if for instance one of your PR got approved after addressing a few comments - and another person who didn't see that reviews the other version.
So it's much better to first land your changes in one branch - which would typically be your development branch - then create a PR that merges these already-merged changes into the other branch.
The way you do that is to first merge your PR into the development branch.
Then, create an integration branch off of current master, git cherry-pick the commit that merged your changes into the development branch (you might want to use git cherry-pick -x and possibly edit the commit message to include a link to that merged PR), then create a PR of that and include a link to the previous PR in the description.
It is a little bit of extra work and not really needed for small projects, but once your project grows, it will become quite important.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论