Main menu:

Site search




Branches beware

The use of branches for software development has become too commonplace. And no wonder, services like github have the best tools for reviewing and team collaboration on changes made in branches. If your team isn’t having discussions about how you use branches, you should, frequently. I’m not saying that branches are always bad, just that they should be used carefully.

A metaphor that I like for branches is that they are like ticking time bombs. The reason is simple: you should value working software, green builds, and quality designs and implementation over everything else.

When changes are checked in frequently to the mainline the potential magnitude of explosions resulting from breaking changes is small. Small problems are easy to fix so it’s easy to keep your software in a good state. On the other hand, the longer a branch is actively worked on without merging into mainline the bigger the potential explosion. Large changes result in large problems and these slow you down.

You may be thinking that sometimes you need to use branches to make large changes. Challenge yourself to think about the problem differently. In my experience, any large change can be made in mainline incrementally. It may take slightly more effort but the results are often better. For example, a few years ago my team realized we needed to change the database tech in our stack. Instead of working in a branch we put the new tech stack into production and routed all data into the old and new systems for a few months. This allowed us to make a data-driven decision on the superiority of the new solution because we compared behavior using the same data over a period of time. We were then able to switch to the new system and delete the old system without any of our customers noticing anything other than better performance. It was so cool.

Summary: keep branches small and merge frequently. If you think a long-running branch is necessary challenge yourself to find another way. You’ll get more done in the long term and be under less stress as a team.

Write a comment