A Guide To Branching (Based in Git)

Whenever we introduce others to a new technology, service, application, or anything else, I think that we – as developers – don’t often do such a hot job of showcasing what the true “beginner-level” features are.

That is, we’re either so enamored at what we’re working with, that we’re eager to show what we’re able to do or we skip to more complicated things without explaining the foundation off of which said things have been built.

Maybe I’m off base, but one of the places I’ve seen this crop up in a few conversations is around the idea of Git branching and merging.

That is to say, I’ve had others ask specifically about understanding what a branch is and what a merge does.

For those who have worked with other source control systems, these terms are taken for granted, but for those who are just getting their feet wet and who are hopping into development (even if it’s with Subversion and its branches directory), these are concepts that seem to be glossed over in an attempt to get to more of the “exciting” parts of source control.

At least, as exciting as it can really get.

A Guide To Branching

Over the next two posts, I’m going to be talking about some beginner-level stuff. So if you’re one of those, you know, fancy advanced developers who can write an operating system over the course of a weekend or you finding yourself compiling and re-compiling the Linux kernel from source just for kicks, then this isn’t the set of articles for you.

But if you’re someone who’s involved in software development and who is new to source control or who is working with source control but feels as if you’re doing so in a bit of a fog, then my goal is to try to clear up some of that beginner fog.

To do that, I want to talk about branching and merging. So in this post, I’ll cover a guide to branching and in the next post, I’ll cover a guide to merging. By the end, you should hopefully have a clear idea as to why these things are so important for working on new features or resolving bugs as it relates to a codebase that’s kept in source control.

But enough talking.

Understanding Branches

So what’s a branch? According to the Git definition, a branch is the following:

A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you’re given a master branch that points to the last commit you made. Every time you commit, it moves forward automatically.

But, as with most definitions, they can be simplified, right? I mean, the technical definition matters, but sometimes,  you just need something to work off of.

Think of it this way:

Branches are copies of the master branch that allow us to work on the codebase without touching the core application.

Your application is made up of a bunch of code. All of the code that makes your application work is the main branch of the code.

In Git, we call this the master branch. In Subversion, it’s called the trunk (like a tree trunk, not a car trunk), so if you’re a visual learner, like analogies, dig foliage, then think of the master branch (or Subversion’s trunk) as the main vein of the program.

Perhaps an image will help. Here’s a program with a single master branch:

Application Master Branch

Here’s a program with a single branch that has yet to be merged back to master:

Dev Branch #1

And here’s a program with two branches created at different times each of which have yet to be merged with the master branch:

Dev Branch #2

The master branch should ideally be the current, stable working version of the code. This isn’t always the case. Many times, you’re going to find that the master branch – or the trunk – is the version of code that’s deployed to a staging environment where tests should be running to ensure that it’s performing how it should.

But a good rule of thumb is that the master branch should be for functioning, shippable code.

Working on The Master Branch?

What happens when you want to work on the codebase without interfering with the code that is working, though? I mean, the tough part of working on source code is that you’re constantly tweaking the life of a proverbial organism such that, at any moment, you could be breaking all the things, resolving all the things, or introduction a portion of something that needs several days to complete.

This is where branches come in handy. So if you’re using Git, then you take the master branch of the source code – that is, the [ideally] working application – and create a branch off of which you can do your work.

When you branch the codebase – or the master branch – you take a copy of the code and create its own sandboxed version of the code and you make sure to tell your source control system that that’s the branch off of which you’re working. In Git, this is called “checking out.”

While your branch – which you can name anything (above, I’ve creatively stuck with Dev Branch #1 and Dev Branch #2) – is checked out, any changes that you make will affect only that branch. It will not touch the core application. This gives you the freedom to tinker, develop, resolve, test, patch, refactor, or whatever else you need to do with your code in order to get it into shape to be shipped along with the master branch.

Okay, though, so let’s say you finish up a new feature or fixing some bugs in the branch in your code – what then? Enter merging.

But we’ll do that tomorrow.