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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…