A branching strategy is a convention that describes when branches are created, how they are to be named and what use your branches should have.
Communication will be clearer if your team uses the terminology correctly and consistently.
Minimise the number of branches
No matter which strategy you use, it is helpful to minimise the number of branches in play. Fewer branches means; less merges, less conflict and less misunderstanding within your team. The most extreme example being Trunk based development – a single branch with feature toggles. For larger code-bases branching allows changes to be isolated – helping teams from disturbing each other. Short-lived feature branches can work well, especially when used for experimentation. When branches remain in existence for too long the chances of multiple merge-conflicts mount.
Merge regularly
For many enterprise businesses deployments are still infrequent. However its essential to merge regularly. Weekly merges are a good frequency to start with. The merge should be performed by the team that is responsible for the target branch of the merge – they know best when to do it and how to resolve conflicts.
There are many branching strategies. Here I evaluate when and where they are best used.
1) Branch by Abstraction / No Branches / Trunk based development
Your team works only from the main source tree. You do not create branches and you do not need isolation. Generally suited to small teams that do not require isolation for teams or features.
The “branch by abstraction” approach has recently gained attention due to the buzz surrounding “continuous delivery”. Our strategy is; a single branch for everything.
New features, but not yet finished, can be enabled or disabled by feature-toggles. We can use this device to release different versions of our application from a single branch, by changing its configuration. The big advantage here; it frees us from merging! Unfortunately – its not appropriate for all projects.
2) Branch for Release / Branch for Sprint / Staircase Model
For every planned release we have a separate branch. Your team creates a branch before release time to stabilise the release and then merges changes from the release branch back into the main source tree after the software is released.
3) Branch for Maintenance
You create a branch to maintain an old build ie a branch for your maintenance efforts, so that you do not destabilise your current production builds.
You may or may not merge changes from the maintenance branch back into the main tree. e.g. your team works on a hot fix for a certain number of customers that you dont want to include in the main build.
4) Branch for Feature
You create branches based on features. You create a development branch, perform work in the development branch, and then merge back into your main source tree. Your team can create separate branches for work on specific features to be completed in parallel.
5) Branch for Team
You branch in order to isolate sub-teams so they can work without being at risk of breaking anything, or they can work in parallel towards unique goals.