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
Best Answer
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.