1

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?

0

5 Answers 5

3

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.

3

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.

4
  • Why is applying "bugfixes" to the release 2.0.8 not intended to be the new release 2.0.9 ? I mean i actual apply a patch or not? On the other side ... if there is always the plan the the current dev is the new "2.0.9" version we probably get version conflicts
    – Jim Panse
    Jan 27 at 8:52
  • @JimPanse: if you don't follow semver (which is likely when you develop an end user product, not an API or library), 2.0.9 for a bugfix release will be find. Semver version numbers indicate whether the public facing part of an API has changed - or not. Bumping only the fourth digit says usually the public API was unchanged.
    – Doc Brown
    Jan 27 at 9:23
  • @JimPanse: I agree with Doc Brown. Version numbers are an arbitrary convention and they don't make or break the validity of your software. If the "current" version is always the leading one and consumers cannot choose to use an older version, version numbers are purely informative and have no bearing on how the application works. If you are publishing a library and past versions remain publically available, the semver standard would be much more important. I prefer following the standards in either case, but in the former case it is not a sticking point.
    – Flater
    Jan 27 at 9:58
  • This answer correctly captures the correct answer: branch the merging in of the bug fix from the labeled basis from which current development diverged, then merge that bug-fix branch into current development so that current development no longer has that bug. (Of course, new development's upheaval •might• have precluded the existence of that bug, which is of course resolving the merge conflict of merging in the bug-fix branch into new development by preferring the redesign that is in new development.) Feb 4 at 16:43
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.

1
  • This answer correctly captures the correct answer: branch the merging in of the bug fix from the labeled basis from which current development diverged, then merge that bug-fix branch into current development so that current development no longer has that bug. (Of course, new development's upheaval •might• have precluded the existence of that bug, which is of course resolving the merge conflict of merging in the bug-fix branch into new development by preferring the redesign that is in new development.) Feb 4 at 16:42
2

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.

8
  • I don't see why it is "poor management" when having a release plan where several bug fixes (maybe not mission critical ones) are collected and deployed first before a new feature release is deployed. Quite the oppsite, this is a standard strategy to stabilize a product in production after a new feature release was deployed.
    – Doc Brown
    Jan 26 at 15:09
  • @DocBrown Based on the question, the developers were working on a mix of stuff that included new features and bug fixes. Then, management decided that their order was wrong and to not only suspend development of new features, but to hold back the finished new features. It's incredibly wasteful (in the lean sense) to do that. Poor product or project management.
    – Thomas Owens
    Jan 26 at 15:23
  • Does not convince me. I don't read the question in the sense that development of new features is suspended, only that management decided to create an intermediate release before deploying the new features. And a management which decides about changing the order of what has to be deployed according to the real situation does not look like not bad management to me, quite the opposite. Bad management is when people stick blindly to a plan, without noticing what really happens.
    – Doc Brown
    Jan 26 at 15:33
  • ... but as I read your answer, you and me perfectly agree that the OPs solution is already in Gitflow, it is indeed the hotfix approach with only minor differences.
    – Doc Brown
    Jan 26 at 15:35
  • @DocBrown Yeah, we absolutely agree on following the hotfix approach to solve the problem.
    – Thomas Owens
    Jan 26 at 16:16
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.