I’ve been doing a bit of reading and thinking about the branching methodology we used on my previous project. There were some good things and also some areas that left me a bit wanting.
I stumbled across these blog posts: Simple Branching Strategy Part 1: Back to Basics and Simple Branching Strategy Part 2: Implementation. I like the posts because it talks about something close to the heart for most developers. The topic of source control and branching strategy has always spurred quite a lot of conversation and debate on my teams, but John seems very grounded and “simple” in his approach. I’m always a fan of keeping things simple.
The methodology John describes is how we did it on my project:
- everyone develops op the trunk
- create a branch off the trunk for each release
- create a branch for POC (proof-of-concept) work
This approached worked well. Whenever we had to release our code we branched and did the deploy (to QA, Staging and Production) from that branch. Bug fixes (only the real big showstoppers) were fixed in the branch for that release before we redeployed that branch. This is where the kicker was: the code change had to be done in the branch and the trunk. Sometimes the trunk was not updated with the code change and this resulted in fixed bugs re-appearing again.
This is obviously not an ideal situation. We addressed this in a couple of ways:
- limit the number of merges between branch and trunk by only fixing the real showstoppers
- encourage discipline by reviewing the list of bugs at our daily stand up meeting to make sure that the people who fixed the bug also merged the change into the trunk
Someone on the team suggested this approach:
- create a branch for each release BEFORE we develop the features for the release
- develop in this branch
- when a feature is complete, merge that into the trunk
The goals of this approach is to have all deployments run off Trunk, and to have smaller, contained and frequent releases.
That really appeals to me. However, we didn’t get the time to try that. I’m considering that approach for my next project.
It’s funny how we emphasize re-using code and principles etc, but whenever we start a new project we want try new things, or change a process. That’s life …