When trying to follow the the gitflow model, we have a branch for the releases. However, we've had complicated merges when trying to merge from develop and bugs have crept in to that branch from this.

What are we doing wrong and how do we keep these merge bugs from showing up?

Our git tree looks like:

d  r  m
|  |  |
o  |  |
|\ |  |
| \|  |
|  1  |
o  |  |
|  2  |
|  |  |
o  3  |
| /|\ |
|/ | \|
o  |  4
|\ |  |
| \|  |
|  5  |

where the o is a change on the development branch. 1 is where the development branch was merged into release, 2 and 3 are commits to fix bugs in the release branch, and then 4 is the release on master. This then continues with 5 being the merge of development into the release branch again.

  • You do not have multiple release branches. You have one. Master. That is it and that is also what is presented on the image. You can have multiple branches for development, and that is all completely fine, but there should always be only one release branch.
    – Andy
    Oct 20, 2015 at 20:51
  • @David that's fine in theory but what about the main release branch and bug fixes to the old versions during their supported lifetime Oct 20, 2015 at 20:56

2 Answers 2


Each branch has its role - its purpose. Its entire reason for being. Once that purpose is complete, the branch should be closed for further changes and merged back into the mainline.

Having a perpetual release branch means that the purpose of the branch is never complete, as it is perpetually open for changes. Each time you have a new release, you find yourself merging from the development branch into the release branch. And this isn't a merge of ideas - it is a complete replacement of the state of the release branch with the current head of development efforts. When it isn't a complete replacement of the state of the code from development (which is in theory, ready for release), it provides a place for bugs to creep in that differs between the release branch and the development branch.

That complete replacement of the state rather than a merge is a distinct hint that the old branch is done and this is a new one. To make that clear to everyone, here is a different release branch.

Consider also the (not unlikely) situation where there are two releases on going at the same time. The release effort takes two months to do (certification, testing, more testing, fixing bugs that show up in that release effort, recertification, packaging for the different builds). And now, one month in, another release effort starts for the next release. This is a different purpose - a different branch.

Or consider the situation where you have a release branch, which you then branch for each platform that you are going to deploy (making the tweaks to get it to work nicely on Mac, Windows, and Unix systems). And while release 1.0 may be out the door for Windows, the Mac and Linux efforts will take another chunk of time(while you are readying the 1.1 release). Again, each of these is a separate release and a separate branch.

One of my favorite whitepapers on branching is that of Advanced SCM Branching Strategies. While this has a focus on perforce (a centralized version control system at the time). The concepts that it puts forward can be clearly mapped into the git-flow model.

In this whitepaper, the packaging role is the one that maps to the git-flow release branch.

The packaging role is often confused with the accumulation or, more commonly, mainline roles. Once the intended development and maintenance have been performed and any accumulation has been done, it is time to prepare the code for release. Such an effort may not be trivial, requiring a team of release engineers and additional fixes beyond those already performed. The policy on a packaging branch is significantly different from that on a maintenance branch, as the packaging role suggests, only the changes necessary to make the product releasable should be addressed.

If work is to proceed on the other product branches, as is likely to happen if patch levels of the product are to be produced, one does not want the release effort to stall progress toward the next patch level. Other packaging branching strategies could even keep minor versions running off of the same mainline, compounding the potential for a stall while the packaging activity takes place.

Using a separate branch to insulate the release effort from the ongoing development and maintenance, and vice versa, is recommended. In a multi-platform environment, it may be advisable to create one packaging branch per platform for the final porting effort. If the porting efforts are staggered, this allows the staggered releases to be reflected in the version hierarchy. If the porting efforts are simultaneous, accumulating the per-platform packagings to a master packaging branch, from which the final build would be performed, should also be considered. This should be determined in advance, as creating the separate packaging branches from the master packaging branch works best.

This is why you separate the release branch from the mainline branch, and also why you separate the release branches from each other.


As shown by your workflow link, develop and master should always be there.

You create feature from develop.Feature branch should be created as per requirement and merged to develop and feature is deleted.

Similarly after release merged into master, its deleted.

The diagram you show is not clear.May be a detailed one can help to provide you an answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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