Why Branching Matters

Prefer reading? The full written version is below

Note: This is the written companion to the video above. Same content, optimized for reading – so you can watch, read, or both, depending on how you learn best.

You already have a basic understanding of version control with Git and have started using it for all your projects where it makes sense to use version control. Depending on your project and team, this may involve:

initializing a repository and adding a remote, or maybe cloning a repository,
tracking files, staging and committing changes locally, and
pushing your commits to the remote repository.

So, what’s next, whether you’re working on your own or as part of a team?

You see a hint in the output of each git status command, next to the name of the branch you’re currently working on:

> git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

It’s time to begin engaging with branching.

Default branching in Git

Whether the branch is called main or master, Git creates a default branch for every new repository.

This branch points to the latest commit, and each commit points to its previous parent commit (or, spoiler alert, parent commits), except for the root commit – the very first commit, which has no parents. This forms the history of the repository, allowing you to see what happened in reverse chronological order. You want to keep this history easy to understand and explore.

But what about when you have a new task to work on that might take a while? Or if you simply want to try an idea and you’re not sure how it will turn out or whether it will work at all? There are ways to go back if you have messed up your main line of development, but you generally don’t want to go down that path, because the main line should stay clean and stable, so you and others can always come back to something working reliably.

What if, instead, you could create a parallel timeline, where you could work undisturbed for a while, and let others do the same in their own parallel timelines? Where you could experiment freely and even discard the experiment if it fails or doesn’t turn out the way you expected? And if it does work, integrate the changes into the “main” timeline?

Well, you can… You can branch off your main branch, test out your idea in the new branch, and merge it back into the main branch if it turns out the way you wanted it to (spoiler alert, this is one of the possible branching workflows we’ll see later). Merges will go smoothly unless the two branches change the same content, in which case you’ll need to resolve conflicts first.

Conflicts are relatively rare when working alone, because you are the only one making the changes. But conflicts occur much more often when working with others. That’s because it’s more likely that different people might edit the same content in different ways.

This is why branching is essential when collaborating: It makes working together on the same codebase and integrating changes easier. Not because branching will stop conflicts from occurring – it won’t. But because branching allows you to control when conflicts happen: Instead of being interrupted in the middle of a task, you can wait until you have something worth sharing and are ready to merge. Note that something worth sharing does not necessarily mean something already finished – you don’t want to isolate yourself for too long, either. The practice of pulling often and merging regularly keeps conflicts manageable and easier to sort out.

In the next module, we’ll see how to create a branch.