Branching and merging is one of the most critical things a development team must work on over the course of a software release cycle. But there’s a funny thing about branching and merging – it’s usually not thought of as part of the development process. How often do you see a user story called “as a developer I want to merge code to trunk”?
The fact that we often don’t follow a process for the branching and merging of code leads to disarray and pain. It really shouldn’t be that hard! Teams end up in “merge hell” and deliver changes late to schedule. This problem stems from the way branches are created. They’re often not part of the process and are created from a specific business need, not a from a development practice.
When development teams do create a branching pattern, it’s usually drawn out on a white board or in a Visio document, and is used as a model for the overall development process. While the intention is good, many times these plans become quite complex for reasons that can’t be foreseen.
So, why even create branches, if they’re too complex, and unaccounted for?
Create branches the right way, and use them as:
- Development Branch – A branch created for a development code configurations and builds
- Integration Branch – A special branch for parallel teams to integrate code
- QA Branch – QA branches for QA teams to create builds and environments
- BETA – A preproduction branch for customer sign-off, etc…
- Production – All of the content that ends up in prod
If we take a more philosophical view of what branches represent, beyond business needs, they actually serve as workflows for different aspects of the software development process.