My previous post discussed the general reasons for branching and illustrated structures that support it. In this post I plan to expand on the reasons to use for branching and strategies teams may adopt to make effective use of branching throughout the development lifecycle.

There are a number of reasons why you may wish to use branching in your system. Some of the major ones are:
  • To allow the development team to be more effectively utilised. You will not necessarily want or need the entire team to be working on stabilising a version rather than working on new features. Additionally where breaking changes are to be introduced this should not stall the rest of the team.
  • To allow updates to released versions. It is not generally acceptable to have to use the latest development version to resolve issues found in released versions, as they may differ significantly and development versions tend to be incomplete and buggy.
  • To allow different groups to focus on their own area without having to constantly synchronise with each other's changes. This is primarily of use in larger projects with distinct sub-projects and I will not be discussing this in detail.
In developing a strategy for branching, there are a number of considerations:
  • Flexibility The strategy adopted shoudl support the development process in use rather than being a burden upon it. Rules around branching should not be a hinderance to the implementation of the chosen process
  • Managability Allowing unchecked creation of branches presents problems in managing the project. The branching strategy should not allow the creation of so many branches that it becomes difficult or unclear as to the contents of each branch.
  • Adoption The branching policy should be readily understood by all relevant team members, and documented to the extent required to convey this understanding.
  • Logical The strategy should make sense. If you can't explain why the policy is the way it is, consider changing it until you can.
The following constitutes my branching strategy. Adapt as appropriate for your environment.
  • Maintain a primary branch for new development. This branch (trunk) should be where most new development is performed. It should be clearly understood that this is a development branch and that it will not be kept in a state suitable for release. As the primary development branch breaking the build for this version should be illegal under international treaty.
  • For each release to be performed create a release branch. This covers such elements as iterations, alpha, beta and release candidate versions, as well as versions actually released to end users. Work to stabilise the version for release should be performed on this branch and merged back into the trunk as appropriate.
  • Minor additional releases may be performed on the release branch, provided appropriate use of mechanisms such as labels (to be discussed in a future post) are used to define the release points.
  • Where a major structural change or other breaking change is to be performed consider creating a branch. This should occur if the change will take significant time or involve a number of team members. This allows the change to be handled under proper source control without halting the rest of the development team. Breaking the build on such a branch is less critical as it exists specifically for this purpose, but there need to be a clear path towards a non-broken state.
  • Where necessary branch from existing branches other than trunk. For instance a service release for an existing version may warrant its own branch if the existing version must still be supported in parallel with the service release version.