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:
We're now looking at moving our code into GitHub and would like to start using Pull Requests, for a couple of reasons:
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.
From the pull request page you can update your pull request's branch using a traditional merge or by rebasing. A traditional merge results in a merge commit that merges the base branch into the head branch of the pull request. Rebasing applies the changes from your branch onto the latest version of the base branch.
Update your pull request branch by rebasing To update by rebasing, click the drop down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch. Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch.
On GitHub.com, navigate to the main page of the repository. Under your repository name, click Pull requests. In the "Pull Requests" list, click the pull request you would like to add to a merge queue. Click Merge when ready to add the pull request to the merge queue.
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:
hotfix
to master
and have someone review it to validate the fixmaster
, create another PR from hotfix
to develop
and see if you run into merge conflicts 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With