Is it possible to merge hotfix branch to both develop and main branch in Github?

Question

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.

Answer 1

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:

1. When you realize you need a hotfix, you create a branch off of main, for example hotfix-1.2.3 (or hotfix/1.2.3). Protect the branch so that PRs are required to merge into it, just like for develop and main.
2. Use a normal PR to merge a feature branch with the hotfix commit(s) into the hotfix branch.
3. Test the hotfix branch.
4. Deploy the hotfix, and merge hotfix into main and also into develop. 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.)

Answer 2

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.