Question

Is there a specific rule I should be using for when to branch in source control? Branches seem to be expensive because they require that the team have extra knowledge about where the features they want to work on should go.

Our development team sometimes finds itself working on a long term feature and a shorter term feature at the same time. That means we end up with:

Trunk
-Branch A (Short Term)
-Branch B (Long Term)

After they complete we have to merge A in to the trunk, then merge the changes to the trunk back in to B to make sure those edits still function. It’s messy.

I am wondering if we can cut down on branches by using Labels (Or tags, or pins or whatever your Source Control Software of choice calls it). Maybe it makes sense to branch for the longer term project, but we could just do the edits for the short term project right in the trunk after applying a label to the stable release. That way we can always retrieve the source code that was stable if we have to do an emergency bug fix, but we don’t have to deal with the branch.

What rules do you use to decide when to branch?

Answer 1

One way to reduce branching is to implement new features (especially smaller ones) directly on trunk. This is how we do it:

• small features, which will are guaranteed to be completed before the next release, are implemented on trunk
• for larger features, we create a feature branch (“Branch B” in your example)
• once we are ready to create a release, we create a release branch (from trunk), e.g. named “branches/2.x”. This branch is then used for testing and finalizing the release.
• once the release is built, we tag the corresponding revision from the release branch (e.g. tags/2.0.0).
• normal development then continues on the trunk. the release branch is used for maintenance of the 2.x line of the product (e.g. bug fixes are merged from trunk, or implemented directly on that branch)