May 15, 2017

Source Code Branching Strategies

By Owen Strombeck

Source code branching can provide great advantages such as isolating features, allowing multiple developers to avoid stepping on each others toes, and even allowing for focused testing. Branching can also introduce overhead and complexity with merging, conflicts and even managing the scope of releases. I reached out to our experts to get their thoughts on branching:

What is your preferred source code branching strategy, and why?

Graham Mueller - Developer
Graham Mueller

In my experience, the branching strategy you (should) use is largely dictated by the project, the number of people working on it, and your ability to continuously deliver. If you’ve got a single developer who is able to immediately release everything, a single master branch that may or may not just be upstreamed feature work you’ve completed is plenty. If you have more than two or three developers actively working in the same code base, spinning your work off into a series of feature branches that are able to be independently code reviewed prior to merging back becomes necessary. The other struggle is your ability to deliver. If your work isn’t something that you can just immediately release, or maybe you’re cherry-picking completed features, having a separate release branch that you merge to becomes necessary.

TL;DR | As simple as possible to avoid confusion, but more complex as your situation gets more complex.

Patrick Maddox - Developer
Patrick Maddox

I prefer to avoid bloated branching strategies. There are definitely situations where having a layer or two of security between your production code and volatile development branches is important. In most cases though, I prefer at most three branches away from the master branch. One aggregate development branch, one for each feature in development, and child to those feature branches, one branch for each code addition that adds value.

David Pine - Developer
David Pine

I prefer to use the common GitHub branch strategy, where feature branches get merged into master via pull request and peer review. At any point in time master can be branched as a “release”. I have followed other branching strategies, but none of them seem as simple. This branching strategy seems to answer all the questions you should ask yourself when deciding on a branching strategy for your project. This GitHub branch strategy has served me (and literally 20 million other users) well for years!

Tyler Evert - DevOps Consultant
Tyler Evert
DevOps Consultant

I steer towards single-trunk/trunk-only/no-branches. Keeping everyone’s work in the same place makes merges tiny, and avoids all questions like:

  • “What branch is that on?”
  • “What branch is in this environment?”
  • “Can I merge this? Should I merge this?”
  • “Where are you at with that; can I take it yet?”

This doesn’t come easily – it requires additional discipline and development techniques. Extensive feature toggling is necessary to avoid releasing partially finished work, which requires a well-fragmented architecture. Note that partially finished code might ride along to production – it’s just not exposed or run. Heavy automated testing is also needed to catch issues as soon as they appear. Small, frequent check-ins keep integration and merging issues lightweight and easy. This is a major shift from most teams’ processes, but the rewards can be great.

What is your branching strategy, and how well does it work for you?

Owen Strombeck - Team Lead, Scrum Master, and Quality Engineer

About Owen Strombeck

Owen is a Team Lead, Scrum Master, and Quality Engineer at Centare and is passionate about team dynamics and agile methodologies. He also enjoys building communities through extra-curricular activities like sports and board games