GitFlow branching strategy, but without the develop branch

Question

I am thinking about adopting something like the GitFlow branching strategy. Instead of using a permanent develop branch, I would like to create a release branch for each sprint (from master) at the beginning of each sprint. Feature branches would be merged into the release branch. Our CI process (TeamCity) would be configured to deploy the latest release branch (based on the version number suffix) to our Integration and QA environments.

My idea here is that we would avoid the need to maintain a develop branch and avoid the need to merge into master and develop when a release is ready.

Would there be any potential drawbacks of this approach?

To clarify:

• sprint/release cycle is typically ~3 weeks
• we need the ability to occasionally release a single feature branch, which may already have been merged to the release branch

Answer 1

There are some drawbacks, I don't see as many benefits.

Not sure how you are avoiding the need to merge into master, unless master stops reflecting the "latest released version"

The major drawback I see is that you are getting a "develop" behavior, but changing the name of your "develop" on every sprint, and getting your CI to point to a different branch every sprint.

The second biggest drawback in my opinion, is fixing bugs. When fixing bugs on an older release, you will have to port them to the current release (and probably some intermediate releases, if customers are using different versions). You made that process harder with your branch structure, potentially managing many more than 3 branches integration.

If you are trying to avoid merging, you are not going to get the benefit of branching.

Answer 2

Its seems to me that you are still doing GitFlow you are just fiddling with the naming of the develop branch.

Now there is a major problem here. Not so much with the renaming/rebranching but with your choice of name.

You want to name the branch with the version of the release. However, you can't know the release version before you get to the point of release.

eg:

• You call your branch release_1.0.0.2 but before you finish it you have to do a hot fix! now your release will be 1.0.0.3

• OK you decide to leave off the build number and call the branch release_1.0.1.x but then you realise that one of your features introduces a breaking change! now you want to change it to release_1.2.0.x

• You start a feature in release_1.1.x.x but its not finished in time for the end of the sprint. now you need to merge it into release_1.2.x.x

All in all you are better off branching your release branches from master when you release them rather than in advance and using things like automatically generated build numbers and tagging to label your release versions in git/source control

Answer 3

I can fully understand you don't want to maintain the develop branch. It it annoying to maintain both master and develop. We have as well dropped the usage of a development branch. We do make sure master is always in a working state. Only potentially relesable code goes into master. We accomplish this using feature branches.

We have usually been releasing from master but we had some minor problems last major release where it was unclear when the "cut-off" was which resulted in the release not being tested as well as we would have liked.

In the future we are talking about release a release branch instead of master. We have these release branches today, but today we merge it to master before releasing which is not optimal.

Immediately after a release the release branch will be merged to master.

The flow you describe sounds like an ideal setup and I can see no major drawbacks. In the future we are probably doing something similar.

Answer 4

I believe that your branching style should be based on your release strategy:

• Product/library development
• Sprint-based releases
• Continuous deployment

Historically, I've focused on product and library development. In that world, you usually have multiple versions in concurrent use, and the implementation might be dramatically different between versions -- so that bugfixes for one version cannot simply be merged into another version. To support this, I use the following structure:

• Feature branches: individual units of work, that start out as part of a release but may or may not end up on that release.
• A Release branch, which receives squashed commits of features (and is regularly merged back to the feature branches to minimize conflicts).
• Master, which contains the most recently released version of the codebase.

The key here is that a Release branch will live on after it's been merged to master, and receive changes that may or may not exist elsewhere. So, for example, while you're working on branch rel_1_9, you may be making a bugfix on rel_1_2, and tag that bugfix with rel_1_2_7.

In this approach, there's actually no need for Master: you can create a new release branch from the release tag, and set it as the default branch. But some people like having master so ...

The alternative environment is one where you make regular releases but never return to older releases (eg, a typical hosted app). In that case, I think the branching strategy depends on whether you practice continuous deployment or sprints.

For sprints, Develop is useful as an integration branch: all new work gets merged into it from Feature branches, but it doesn't get merged to Master until the sprint is done. During the sprint, hot-fixes may get committed to Master and then merged into Develop. There's really no reason to create separate branches for each release; if the branch is never touched after merge, it's semantically identical to a tag.

And if you're doing continuous deployment, I recommend that you retain Feature and Master branches and get rid of develop. If you have multiple developers merging their work into Develop before Master, you will have a situation where unintended changes get merged and deployed.

Shameless self-promotion: http://www.kdgregory.com/index.php?page=scm.git

Answer 5

In my company, we use a similar approach (in that we have release branches created after each sprint, but instead of develop, we have somehow decided to dispense with master). I think the rationale is to keep releases maintained "forever".

This strategy makes sense if your product is going to be installed in multiple machines and you do not have control over when those installations upgrade to a different version. If you follow GitFlow, older releases are reachable, but they are not so easy to be patched, especially after you have merged newer versions into master. Such products would be e.g. desktop applications or stand-alone systems.

This strategy makes much less sense if your product is a service, and you have complete control over when it is upgraded: you install the newer version in your servers, and clients do not get to choose which version they speak to. Any web service is an example.

In short, both strategies are doable, both can have upsides and downsides; I think the degree of control over releases you have is what should guide your decision.