Using branches in your day-to-day work might very well prove to make you a better programmer or designer. Be that as it may, it's definitely one of the main reasons why Git is so highly respected. And although desktop GUIs like "Tower" make all of this a lot easier, it still makes sense to have a firm understanding of the underlying concepts!

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).
• Besides, you also update some content on your FAQ pages (context 4), while...
• your teammate 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.

This was an excerpt from my (completely free!!) online book "Learn Version Control with Git". Feel free to read more if you want to understand How branches can solve these problems, How to create and manage them, How to integrate changes between branches and where remote branches come into play.