Branching can Change Your Life

This is quite a sensational headline, I know... But the truth is: it's not an exaggeration. Using branches in your day-to-day work might very well prove to make you a better programmer or designer.

First of all, if you're coming from another version control system, I kindly ask you to forget the things you already know about branching & merging. It's true that Git hasn't invented this particular wheel: many other VCS also offer branching. However, Git's concepts in this area are absolutely unique when it comes to ease of use and performance.

Now, let's look at why branches are so important.

Working in Contexts

In every project, there are always multiple different contexts where work happens. Each feature, bugfix, experiment, or alternative of your product is actually a context of its own: it can be seen as its own "topic", clearly separated from other topics.
This leaves you with an unlimited amount of different contexts. Most likely, you'll have at least one context for your "main" or "production" state, and another context for each feature, bugfix, experiment, etc.

In real-world projects, work always happens in multiple of these contexts in parallel:

• While you're preparing 2 new variations of your website's design (context 1 & 2)...
• you're also trying to fix an annoying bug (context 3).
• On the side, you also update some content on your FAQ pages (context 4), while...
• one of your teammates is working on a new feature for your shopping cart (context 5),...
• and another colleague is experimenting with a whole new login functionality (context 6).

A World Without Branches

Not working in clearly separated contexts can (and sooner or later will) cause several problems:

• What happens if your client likes variation 2 of the new design? In the meantime, a host of other changes have happened! How do you launch the new design while integrating all these other changes instead of losing them?
• What happens if the shopping cart feature became obsolete because the client changed his mind? How do you get all that unwanted code (and only that code!) out?
• What do you do if that new login functionality proves to be impossible to implement? It's already mingled with all of those other changes, being almost impossible to separate out!
• How can you avoid losing track? Most likely, you shouldn't be bothered with all the topics from all of your colleagues.

Things will start to get very confusing when you try to handle multiple topics in a single context:

A tempting workaround might be to simply copy your complete project folder for each new context. But this only leaves you with other problems:

• You circumvent your VCS, since those new folders won't be under version control.
• Not being version controlled, you can't easily share & collaborate with others.
• Integrating changes from one context into another (maybe your main context) is difficult and error-prone.

To make a long story short: if your goal is to work professionally, you'll have to find a way to deal with multiple contexts in a professional manner.

Branches to the Rescue

You might have already guessed it: branches are what we need to solve these problems. Because a branch represents exactly such a context in a project and helps you keep it separate from all other contexts.

All the changes you make at any time will only apply to the currently active branch; all other branches are left untouched. This gives you the freedom to both work on different things in parallel and, above all, to experiment - because you can't mess up! In case things go wrong you can always go back / undo / start fresh / switch contexts...

Luckily, branches in Git are cheap & easy. There's no reason not to create a new branch when you start working on a new topic, no matter how big or small it might be.