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
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