Below is the Gitflow workflow followed, where master branch has the commit history(git tag) of different releases.

From release mgmt aspect, we are deleting the release branch after merging with master and develop branch.

enter image description here

To apply hot fix, we first git checkout a specific release commit from master branch and then create a hotfix branch from that specific commit(shown in orange, below) and make changes.

enter image description here


1) Does git merge allow hotfix branch to get merged to intermediate commit node(as shown below) on master branch? instead of merging to tip of master, because hotfix is for 0.1 release

enter image description here 2) If no, How to apply hotfix(of a specific release) through master branch? because release branch is deleted

  • How long do you keep giving hotfix support on old releases? – Bart van Ingen Schenau Feb 18 at 14:21
  • @BartvanIngenSchenau Duration of a release in production environment is revenue driven, where customer is satisfied with functionality provided by that release – overexchange Feb 18 at 14:29
  • So, the hotfix will only exist in v 0.1 but not in 0.2 ? – Pieter B Feb 18 at 21:50
  • @PieterB every release has production issues... so hotfix should be given through that release. – overexchange Feb 18 at 21:59
  • The issue I have is that you basically break the flow of the master "line". When looking at a commit history of your master they're points in time of the state of your code. Adding the hotfix to 0.1 breaks that line, there's no line between the second and third blue dot, because that third dot on your master reverts your hotfix. Dots represent "state" of codebase. – Pieter B Feb 18 at 22:09

You are actually asking how to manage multiple productive versions. Gitflow does not cover this and it's a complicated topic.

You can have a branch per supported version, e.g. version/1.9.0, and do a "nested gitflow" where you treat that version branch just like your master. This should work well enough until you want to back/forward port fixes.

Unfortunately, i don't have any experience with that so cannot help more than this.

To answer the literal question:

This is not possible. One could rebase all of the following history, but that creates so many inconveniences and troubles that it's not an option.


As marstato says you'll need multiple version branches to be able to support multiple minor (or major) releases. Along side to these version branches you'll have fix branches. You don't really have a master branch anymore.

So in your situation you have a version/0.1, version/0.2 and version/0.3 branch. And a fix/0.1, fix/0.2 and fix/0.3 branch. When there is a bug found in the 0.1 version you apply that fix on the fix/0.1 branch, merge that fix branch into version/0.1 and in fix/0.2. Then you merge fix/0.2 in version/0.2 and fix/0.3 (and so on). Finally you merge your last fix branch in its corresponding version and branch and into your develop branch.

When you no longer need to support a version you can delete the version and fix branch of that version and skip them when merging.

Be advised that this introduces a lot of overhead, certainly when supporting a lot of versions. You can reduce the overhead by only periodicaly merging fix branches, but that introduces the problem of having your testing team to know which hotfix has been merged already in which version.

Below you'll find a short example with a version 0.1 and 0.2.

Example of the proces described above

  • Is it not better to not delete release branch and then create hotfix branch through release branch? – overexchange Feb 19 at 12:37
  • Not entirely sure what you mean. You only want to delete a release branch when youré no longer interested in that minor version. The fix branch will always exist as it will be merged into other fix branches (or into develop). That I should probably place into the answer as well. – pkempenaers Feb 19 at 12:40
  • 1) When you say: you'll need multiple version branches, are you referring to multiple release branches forked from develop branch? 2) When you say: you have a version/0.1 branch, do you mean, release 0.1 branch forked from develop branch? – overexchange Feb 19 at 14:20
  • You can indeed name them relaese branches, they however are not forked from develop. but from a previous release branch. As you can see in the example the version/0.2 branch and the fix/0.1 branch were created when 0.1.1 was released. – pkempenaers Feb 19 at 14:35
  • From which branch v0.1 release branch forked from? – overexchange Feb 19 at 14:46

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.