How to properly manage bugfixes for released versions in git flow

Question

We follow git flow, see https://nvie.com/posts/a-successful-git-branching-model/

Lets imagine the following situation:

We have a current version 2.0.8 on our prod environment. After a while, several bugs appearing that need to be fixed (no hotfixes, because they are not critical but more urgent than new features). But in the meanwhile the development on dev branch is ongoing and many new features and other bugfixes are already on current dev branch. However, management decides that the next version is just about fixing the recently discovered bugs, but without any current new features.

Where does the bugfix take place in this case?

For me it cannot be placed on a new branch from current dev because this also would involve the new features we don't want right now ...

Intuitively I would say, branching from the current deployed master tag (2.0.8), applying the fixes and merge back to master and tag it with a new version (2.0.9). Then merge the changes also to the current develop (hopefully nobody touched the code in the meanwhile) ... but I wonder why there is no such case shown in the git flow graph? What do I miss here?

Answer 1

You are on the right track. Hotfixes to production should be branched from the master branch.

I know you're not calling it a hotfix, but it functionally is, as it will go before any new feature release. Hotfixes are not (solely) defined by their urgency.

I don't consider a hotfix as a version upgrade though. It's a fix, not a feature release. You should retain the same version number, possibly with an added suffix (2.0.8.1) so that it gets picked up as the "new 2.0.8" following the semver standard.

Note that if 2.0.8 is already "hotfix 8 of v2.0", then you are correct about it being 2.0.9. But if 2.0.8 is a feature release, then the hotfix should be a lesser version increase.

Answer 2

You can deal with them almost like hotfixes (or simply call a hotfix branch "bugfix branch"). Distinguishing between hotfixes and "less critical fixes" does not make a huge difference for the model, the branches and the assignment of version numbers, so I guess for the Gitflow inventors left that out for the sake of simplicity. The Gitflow model is complex enough as it is.

Note what you described ("branching from the current deployed master tag, applying the fixes and merge back to master and tag it with a new version") are exactly the same steps which are executed for a hotfix. Of course, I agree to Thomas Owens answer that there may be a difference in urgency and fact some of the bug fixing code may already exist in the development branch and hence should be cherry picked from there. The latter is usually not shown in the popular Gitflow diagrams.

Answer 3

Normally you would have every released branch tagged in git. So you look for the tag, and start branching from that. So if you want 2.0.8 with fixes, you branch from 2.0.8. Eventually you are done and tag that branch as “2.0.8 fixed” or “2.0.8.1” or whatever feels appropriate.

And then you merge this branch into your current development branch, which should be based on 2.0.8. Merging it into a master branch may not be a good idea.

Answer 4

Ideally, management should have thought about this when ordering the work for the development team and scheduling the release.

I'm not surprised that the standard GitFlow model doesn't account for this, since it's more indicative of poor product and/or project management than something that a branching model should be concerned with. The model expects that features shouldn't have been merged into the development branch until they were slated for the next release.

I would recommend your solution. However, this is described in the GitFlow branching model since it's the hotfix approach. The difference is that you will need to cherry-pick existing bug fixes out of the development branch and apply them into the hotfix branch. Any new bug fixes not yet implemented can be put directly into the hotfix branch.

The biggest difference is the sense of urgency. Hotfixes are generally used for fixing critical bugs. You're using the approach to work around poor management.

Answer 5

I agree with the other answers that the default solution for you would be to create a hotfix branch off of master, and put the bug fixes there. However, since you mentioned some of the bug fixes may already be on develop, you might be able to create a regular release branch from develop. The key point here is that when creating a release branch, you don't have to start from the tip of develop; instead you can start from any commit that you'd like. So, start from the merge-base of develop and master and trace up the commits on develop to see which ones you want in your new release. If you get at least one or more commits, then you can create a release branch and use that like you normally would, instead of using a hotfix.

Tip: Regardless of whether you call it release or hotfix, if some of the bug fixes you want on your branch are already on develop, if the identical commits can be merged in (perhaps because they branched earlier and weren't rebased onto develop before merging in), then merge those same commits into the new branch. If they can't be merged in, then when you cherry-pick them, use the -x option. This will automate adding the original commit ID information to the "copied" commit, so that future readers of the history graph could see that this was done intentionally.

Lastly, a comment regarding this statement:

Then merge the changes also to the current develop (hopefully nobody touched the code in the meanwhile) ...

Actually, one of the great things about Git specifically is you don't need to worry (much) about others touching the code. In the worst case scenario you will have some merge conflicts to resolve, but that's still better than the alternatives of forcing code freezes on particular files or branches.