I don’t really think feature branches and release branches can be compared as they are two types of branching methods employed at different stages of an iterative development process. Feature branches are generated off the trunk or another branch for the sole purpose of allowing a team to add a single feature to a product in complete isolation from the branch it was created from. When the feature is complete the branch can then be merged back into the branch it was originally sourced from.
A release branch is created to build a shippable version of a product. It generally consists of one or more features and therefore may have multiple feature branches merged into it.
How the release is shipped is then is a team decision based on the scale of the project and the number of branches being ran concurrently. If no other branches are running off the trunk, the release branch could be merged back into the trunk and a shippable build generated off the trunk. Alternatively, a shippable build could be generated off the release branch prior to merging the branch back into the trunk.
Lately, I’ve generally manage development of National Rural using release branches consisting of two to three features, developed sequentially where possible for the following reasons:
- A working demo version of the release can be available for the stakeholders as soon as possible showing one or more of the features working.
- Developing in small iterations generates less pain when the time comes to merge the branch back into the trunk!
As I only tend to run one release branch at a time, the branch is then merged back into the trunk and a build and release is generated off the trunk. I then tag the trunk with the release number so I can always revert back to the tagged version if the next merge goes horribly wrong.
When working in a team on a branch…
- Always update your working copy after another team member has checked in and the branch has built ok to keep your working copy up to date.
- Never, ever, check in code that you know will break the branch build. An unbuildable branch stops other developers jumping into the branch to help out and generally pisses off the work force.
I think this methodology is flexible enough to adapt to much larger teams developing on multiple branches but would welcome any alternative views on this.