Branching in Source Control

Created: September 17, 2020

Continuing my analysis of the ongoing source control survey, I think it's time we talk about branching:

To the two of you who asked "What is branching?" - Thank you; I'm glad you asked!

Branching is a reasonably straightforward concept with metric tons of detail and nuance behind it. There is a near-infinite amount of information and ideas and strategies for branching, so I'll let you study all that on your own time 😃

We're just going to focus today on what branching is and the power it gives development teams.

Yesterday I did a lot of talking about the "main" branch. In git, "main" is the default name for the initial branch of the source control repository. It has other names in other systems, but in general, you can think of it as the primary development stream for the team. If multiple developers are working on the same project, and they're all committing to one single stream, there are going to be a host of problems. They're going to be stepping on each other with changes in the same files, there are going to be conflicts that take hours to unravel, their changes might not play nicely together, and you never know which commit is going to be a good stable one that's ready for release - or worse, you have to halt development entirely so everyone can come together to get a release commit in shape.

Branching is the source control feature which lets us separate out development into multiple streams so that everyone is working in isolation from each other. Let's say in our next release, we're adding a new spectacular automated Invoicing feature, but we also need to fix a bug in the email notification system released last time. Our developers need to work on them simultaneously in order to get the release out on time.

Our developers first update their main branches to the latest version, then our first developer, Charon, makes the branch for her feature using the checkout command with the -b option:

> git checkout -b feature/invoicing

and our second developer, Craig, makes a separate branch for his feature:

> git checkout -b bugfix/email-notification

Now each one has a separate branch in the repository. Charon's code for the new invoicing feature is not going to affect Craig's code for the email notification bug fix and vice versa - until we want those two pieces of code to merge and explicitly, intentionally put them together.

They progress, doing their development as normal, making new commits on their separate branches. When either of them is done and their code passes code review (PLEASE tell me you're doing code reviews) and tests successfully, it is ready to be merged back into main, which integrates the new code into the main body of code.

> git checkout main
> git pull
> git merge feature/invoicing

Any other ongoing development continues - completely unperturbed - in its own branch until it too is ready to be merged.

You can extrapolate the branching concept out to a ton of useful applications: maintaining separate releases or betas, isolating code for user testing, tracking what's deployed in a specific environment, automatically deploying to a specific environment to name just a few. Once you understand the basics of branching, there are a ton of decisions to make before applying it to your team's workflow - why make one, when to make one, when to merge one, which merge strategy to use, and on and on. There are lots of good common strategies to research, but no one can decide what's best for a team except that team.

That said, there's no reason you can't get guidance on these decisions from someone who's been there and done that repeatedly, and I'd be happy to help your team figure it out.

Not using branching? Why not?

Have a super effective branching strategy? Share it!