Git branch between hotfix and develop

Jimyx 0
Viewed 30

I am currently developing a branch flow based on GitFlow, I am in the stage of defining how the interaction between the hotfix branch and the develop branch will be done after a correction in production, although GitFlow recommends that a direct merge be done, I particularly want consider an intermediate branch through which to create a Pull Request and in this way peer review can be done, in addition to avoiding committing directly to the "release" and "develop" branch. The simplest way to do this is to use a feature branch, however it is not appropriate to use it.

Please does anyone have any suggestions for the definition of the name of this branch that I need? I'm considering using a "develop-integration" branch.

git-flow
1 Answers

First, let's reiterate what Git Flow recommends for hotfix branches:

  1. Create a branch for the hotfix, perhaps hotfix-number or hotfix/number, based on master (or main if you call it that instead).
  2. Merge the hotfix branch into master when you deploy to Production.
  3. Also merge hotfix into release if it exists, or develop if release doesn't exist, and now delete the hotfix branch.

For #1, the branch name of the hotfix doesn't actually matter. In Git branch names are simply to help us know what they are for, but you could call your hotfix branch fix-some-bug if you want to. This also translates to your last question:

...does anyone have any suggestions for the definition of the name of this branch that I need?

In the context of an in-between branch, perhaps even moreso than a hotfix branch, it really doesn't matter. In one of my repos where I use Git Flow, we named this in-between branch temp/merge-hotfix-into-develop since it only exists for a few minutes.

Note for #3 above about merging, after using Git Flow for a while, my preference, for both release and hotfix branches, after merging into master, is to then merge master into develop rather than the release or hotfix branch itself. This is slightly cleaner in the long run, but the end result state is identical. Therefore, since I do it this way, my actual branch name in this case would be temp/merge-master-into-develop.

That being said, I'd like to challenge your reasoning for this in the first place:

... although GitFlow recommends that a direct merge be done, I particularly want consider an intermediate branch through which to create a Pull Request and in this way peer review can be done, in addition to avoiding committing directly to the "release" and "develop" branch.

In Git Flow, anytime you are merging one shared branch into another, we can divide the merge into 2 categories:

  1. The merge does not have conflicts.
  2. The merge does have conflicts.

In scenario #1 (which hopefully is the most common scenario), there is nothing to be reviewed, so the PR should be basically automatic. In this case simply create a PR from hotfix (or master) to develop and complete it. You can do a sanity check first if you want to, but it should be extremely rare that it would fail at this point. If the sanity check fails, then you could resort to treating this like #2.

In scenario #2, this is when you need to create the in between branch as you mentioned. I always test the merge first, and if there are conflicts I'll create a branch, as mentioned above, like: temp/merge-release-into-develop or temp/merge-master-into-develop, resolve the conflicts myself (except in rare cases when I can't in which case I'll pull in other devs), and push out the branch and create the PR into, in this case, develop.

usera2M0
Related