An Introduction to Branches

Today, we’ll talk about the concept of branches - one of the most important features in Git.

What Are Branches?

First, what are branches at all? They are a bit like “folders”. And just like folders, they’re used to keep order - to keep separate topics separate. A “topic” can be a new feature that you’re starting, or an experiment, or just a little bugfix. In Git, you typically create a new branch for each topic.

Without branches, everything gets crammed into the same context. Commits from all the different topics all end up in the same context.

Using branches, as said, every topic gets its own context where commits are made. And these contexts are kept separate from each other.

Keeping Separate Topics Separate

Why is keeping things separate from each other so important? Let’s look at a couple of real-world situations.

New code will - almost inevitably - contain bugs or problems. If you mix this new code with your stable work, it will introduce these problems into your production code. This will affect your teammates because they will also receive these problems.

On the other hand, when you keep your new code in a separate context, any bugs in that code will only affect this very context. You can mess up as badly as you might - and neither affect any other context nor your teammates in those other contexts. This is great to know.

Also, keeping separate contexts makes it easier to understand what happened. To stay up-to-date with your project, you need to inspect the commit history. But, especially in a bigger project, you can’t have a look at all commits in all contexts. You only need to understand the changes in your contexts, the areas that you’re working on.

We’ve used folders as an analogy to explain branches. Can’t we just actually use simple folders? The one thing folders do well is: they create separate contexts. But they are terribly inefficient and inflexible when it comes to managing these contexts.

For example, you’d copy the complete project on your disk - which is very inefficient.
When you have a couple of those folders, how do you know what exactly was changed there? Did anyone take the time to document this? Very unlikely…

Also, the contexts become outdated very quickly - because the project moves on with other changes.
And lastly, how do you integrate your changes into the main project again? By searching for the changed bits and fiddling them into the current version? Very tedious and error-prone.

Branches make all of this very easy:

• They’re very efficient because they don’t need to create copies of your project files.
• Also, you can easily see what was changed exactly - because all changes are there as a history of commits.
• And you can integrate changes from one branch into any other very quickly - using the “Merge” feature.
• Last not least, they’re very easy to manage: creating and deleting a branch is a matter of seconds.

When to use branches?

When you’re asking yourself if you should create a branch, the answer is probably “yes”. In Git, Branches are very lightweight. They can be created, integrated, and deleted in seconds. There’s no overhead involved.

Therefore, you should create a new branch really for each topic in your project: for a new feature, a new experiment, or just a bugfix.

Before we dive into working with branches in practice, we have to talk about a couple of terms first.

Pointers and the HEAD

At any point in time, only one branch in your project is currently active. This is also called the “checked out” branch or the HEAD branch. All changes, all commits that you make are made in this branch only.

Also, please note that branches are not optional in Git - you are always working on a branch in Git.

Switching the Active Branch

Now, if there’s an active branch, there must be a way to switch to another branch. This is done using the “checkout” command. If you’re coming from Subversion, don’t confuse this with the “checkout” command there.

So, checkout moves the HEAD pointer to a different branch. It makes that other branch the currently active one.

In the background, a couple of things will happen: Git finds out which commit / which revision this branch is currently at. It then replaces your project’s working copy files with the ones that belong to this version.

Integrating Branches

Lastly, I’d like to mention “Merging”. There’ll come a time when you want to integrate the changes from one branch into another one. For example, when you’ve finished working on a feature you’ll want to integrate your changes into the main line of development.

Merging lets you do exactly this: it takes all the commits you don’t have, yet, and integrates them into your current HEAD branch.

So, you’re now equipped with the basic concepts behind branching and merging. We’ll explore all of this in practice in our next videos. See you there!