Branching strategy
If you think picking a branching strategy is easy, think again. I've gotten lost, pulled out my hair, and had close encounters with complete chaos. I've tried to capture my experience in this article. It's a snapshot of my understanding of the concepts of branching. Take it for what it is, people have written bibles about this topic, and this is a mere one-pager.
Choose an effective branching strategy
Creating branches is useful for isolating risks.
- The software has a current version (in production) and an ongoing version (in dev). Although most of the development effort is invested in the current version, it still needs to be supported with occasional releases (critical and other changes) on the current version.
- The test team needs a stable version of the code to test, and yet the developers have to keep moving forward with new features that will occasionally destabilize the product.
- A few feature teams, each working on a set of functionalities that is reasonably normal. But each team also depends on functionality built by other teams. You need to isolate the risk of the changes being made by the work of each of these teams, and ultimately you need to merge all their efforts into one product.
None of the branching scenarios are immutable. Therefore, quick repairs can be carried out on e.g. release branches.
Develop each strategy to match your needs, without overlooking the complexity and associated costs.
Avoid having changesets waiting for too long before they are merged. The number of merge conflicts is directly proportional to the time the changeset has been waiting to be merged.
Set the threshold for branching high and only do so when there is a need for code or release isolation.
Main only
Can be expanded with the use of Labels. You can mark development and release milestones with labels.
Start with the "Main only" branching strategy.
is the recommendation from Microsoft, then branch out strategically and adopt other strategies to develop into more complex strategies as needed.
Development or Feature isolation
When you need to maintain and protect a stable main branch, you can branch one or more branches from the main branch. It enables isolation and simultaneous development. Work can be isolated into branches of development by function, organization, or temporary collaboration.
Changes can occur in the main branch, so forward integrate (FI) from the main to the development or feature branch must always be done and merge conflicts resolved. Then a reverse integrate (RI) of changes can be done back to the main branch.
Maintain the same quality line across branches.
Run build and build verification tests on the Dev-branch the same way you do on the Main-branch.
With this strategy, developers will likely keep the dev branch forever, potentially building a great merger story.
Feature isolation is a special derivation of the development isolation, allowing you to branch one or more feature branches from main, as shown below, or from the dev branch.
Keep the service life of the functional work and the associated functional branch short-lived. Rollback functionality on the main branch can be costly and will affect testing.
Release isolation
Release isolation introduces one or more release branches from main. The strategy allows simultaneous release management, multiple (and parallel) releases, and codebase snapshots at release time. We really don't need that since the building creates a model package with source code, but sometimes an issue of such a magnitude occurs that we make a copy of the production environment and want to debug the issue. Then it's really valuable to have the release code available.
- When the release is ready to be locked, it's time to create a new branch for the next release.
- Never run forward merge from main. Lock release branches using access permissions to prevent accidental changes to a release branch.
- Fixes/changes made to the release branch must (should) be reverted to the main branch.
Servicing and release isolation
Service and release isolation strategy introduces service branches. This strategy allows simultaneous service management of service packs and codebase snapshots at the time of release.
Use this strategy if you need a service model to upgrade customers to the next major release and add-on packages per release.
Conclusion
The conclusion is that there is no conclusion. There is no wrong or right, do what works for you. I've ended up using Development and Release isolation. This way I can always develop stuff and check that into the Dev branch, move stuff from Dev to Main, and when ready, create a release branch. Each time I do a release, I create a release branch and delete one. I keep only 3-5, as the likelihood of rolling back in production is very slim.
