before release, the trunk becomes almost sacred. Every code change gets reviewed carefully to ensure that we don't regress backwards.
At the moment of release, a branch gets created. This branch becomes our maintenance tree for that release. Our current maintenance branch is called "3.0," since that's the current major version number of our product. When we need to do a bug fix or patch release, it is done in the maintenance branch. Each time we do a release out of the maintenance branch (like 3.0.2), we apply a label.
After the maintenance branch is created, the trunk once again becomes "basically unstable." Developers start adding the risky code changes we didn't want to include in the release. New feature work begins. The cycle starts over and repeats itself.
When to Branch? Part 1: Principles
Best Practice: Don't create a branch unless you are willing to take care of it.
A branch is like a puppy.
Your decisions about when to branch should be guided by one basic principle: When you create a branch, you have to take care of it. There are responsibilities involved.
- In most cases, you will eventually have to perform one or more merge operations. Yes, the SCM tool will make that merge easy, but you still have to do it.
- If a merge is never necessary, then you probably have the responsibility of maintaining the branch forever.
- If you create a branch with the intention of never merging to or from it, and never making changes to it, then you should not be creating a branch. Use a label instead.
Be afraid of branches, but not so afraid that you never use the feature. Don't branch on a whim, but do branch when you need to branch.
When to Branch? Part 2: Scenarios
There are some situations where branching is NOT the recommended way to go:
- Simple changes . As I mentioned above in my "Eddie" scenario, don't branch for every bug fix or feature.
- Customer-specific versions . There are exceptions to this rule, but in general, you should not branch simply for the sake of doing a custom version for a specific customer. Find a way to build the customizability into your app.
And there are some situations where branching is the best practice:
- Maintenance and development . The classic example, and the one I used above in my story about UltraHello. Maintaining version N while developing version N+1 is the perfect example of a time to use branching.
- Subteam. Sometimes a subset of your team needs to work on something experimental that will take several weeks. When they finish, their work will be folded into the main tree, but in the meantime, they need a separate place to work.
- Code promotion . If you want to use the dev-test-prod methodology I mentioned above, use a branch to model each of the three levels of code promotion.
When to Branch? Part 3: Pithy Analogy
- A branch is like a working folder for multiple people.
- A working folder facilitates parallel development by allowing each person to have their own private place to work.
- When multiple people need a private place to work together, they need a branch.
In the next chapter I will delve into the topic of merging branches.
Eric Sink is a software developer at SourceGearwho make source control (aka "version control", "SCM") tools for Windows developers. He founded the AbiWord project and was responsible for much of the original design and implementation. Prior to SourceGear, he was the Project Lead for the browser team at Spyglass (now OpenTV) who