How to do hotfixes with GitHub Pull Requests

Dan picture Dan · Feb 14, 2017 · Viewed 9k times · Source

Caveat: I am fairly new to both git and GitHub.

So, in my current setup, my team uses git flow Hotfixes (usually started and finished by a graphical tool such as GitKraken or IntelliJ) to make changes that have to be merged into two branches and pushed upstream in both. So for example the flow would be:

  1. Pull latest from master
  2. Start hotfix
  3. Commit changes
  4. Merge hotfix branch into both master and develop and push both upstream

We're now looking at moving our code into GitHub and would like to start using Pull Requests, for a couple of reasons:

  • CI hooks to run tests and stuff
  • a place to put code-specific comments not directly related to the underlying "issue"
  • avoiding the need for everyone to constantly be pulling the latest master/develop to their local machine so that they can merge changes

But in the case of Hotfixes, I'm not sure what to do because I'm merging into two branches but it really is one "action" so manually creating two pull requests seems weird, particularly since step 4) in our current flow is a single click.

Is there a smart way of handling this? My ideal case would be that pushing the Merge button on the Pull Request would just merge into both, but that doesn't seem to be an available option.

Answer

Mickaël Derriey picture Mickaël Derriey · Feb 17, 2017

As you mentioned, a Pull Request has only one target branch, so you won't be able to push the hotfix to both master and develop by merging one Pull Request.

I'm also surprised you mention your step #4 - merging the hotfix branch to both master and develop and push upstream - is one action. While there's a high chance the merge from hotfix to master won't run into merge conflicts, I can't say the same for the merge from hotfix to develop since it could have been worked on since the last deployment to production.

My recommendation would then be the following:

  • Create one PR from hotfix to master and have someone review it to validate the fix
  • Once it's merged into master, create another PR from hotfix to develop and see if you run into merge conflicts
    • If that's the case, resolve the merge conflicts so the PR ends up in a state to be merged, and have someone review the PR
    • If there's no merge conflicts, then have someone review the PR

An alternative solution, if you really want to go down the automated path, would be to leverage both GitHub webhooks and API.

The webhook would allow you to be notified when a PR is merged. You could inspect the payload to make sure that the base branch starts with hotfix/ and the target branch is master. You could then react to that event by using the API to create a new PR from the same hotfix branch to develop.

It will involve some development, and the effort might not be worth since creating a PR via the UI is still quite easy and quick.