What are Git Branches?

Git is a fundamental tool that developers use daily to manage our project’s source code and track its changes. It’s a complex tool, too, and it’s often not very intuitive, but it’s extremely powerful, and it can sometimes become intimidating. However, we’re used to adding files and committing changes with just a few commands, and in this way, we take snapshots of our work to which we’re able to travel back if needed. But Git is a far more powerful tool that allows us to do more than just that. Let me introduce you to Git Branches.

When working on a project, we add features as we progress on it, and sometimes those features break our layout or code that was functioning without issues up to that moment if we work on a single branch.

What are Git Branches?

Git Branches allow us to work on different versions of our code simultaneously. Think of branches as alternative timelines.

Git Branches allow us to create separate contexts where we can try new things or even work on multiple ideas in parallel without risking the codebase.

If we make changes on one branch, they do not impact the other branches until we merge or integrate the changes.

The Master Branch

In Git, we are always working on a branch. The default branch name is master (or main).

The master branch is not special in any way or has any superpowers. From Git’s perspective, the master branch is just like any other branch, and it does not even need to hold the master copy of your project.

Many people designate the master branch as their official branch for their codebase, but that is left to you to decide.

You can list your existing branches with the command 

$ git branch

Look for the *, which indicates the branch you are currently on.

Branching And Head

Git calls HEAD to a pointer that refers to the current “location” in your repository. It points to a particular branch reference.

HEAD always points to the current commit you are viewing. By default, that is the tip of the branch you designated as the master branch of your repository. That tip is the most recent commit on it, although you can move around and HEAD can change.

Use

$ git branch <branch-name>

to make a new branch based upon the current HEAD.

When you create a new branch, they get created from the current HEAD, which generally is your latest commit.

This just creates the branch. It does not switch you to that branch (the HEAD stays the same).

You can use 

$ git switch <branch-name> 

to switch to it. This effectively makes HEAD point to the last commit of that branch.

Switching back to master simply moves the HEAD back to the master branch.

Every time we make a new commit, it only exists on the new branch, not on master!

You can also use the following shortcut:

$ git switch -c <branch-name>

Use `git switch` with the -c flag to create a new branch **AND** switch to it all in one go.

If you branch further from this branch, the new one includes all the commits from the one from which it was created.

Historically the command

$ git checkout <branch-name>

was used to switch branches. While this still works, the checkout command does many additional things, so the decision was made by Git maintainers to add a standalone switch command that is simpler to use and remember.

Advantages of branching

The advantages of using branches are several:

If you work alone on the project, you can work on different versions of your code simultaneously.

Additionally, you can easily switch between different branches and compare their changes without taking the risk of corrupting your work in case the feature branch breaks the code on your master branch.

It’s entirely up to you when or if you want to merge the changes from the feature branch back to the master branch. Even more, it’s up to you which parts of your code to merge since it doesn’t necessarily need to be the whole code on the feature branch.

But it is when working in teams that branches really shine. Typically a developer is assigned a branch to work on a particular feature. Then, if the feature breaks the code, the developer can easily switch back to the master branch to fix the issue without risking the team’s collective work.

Many branches can coexist in parallel while different developers or teams work on different features.

These branches can eventually be submitted for review, sent back with corrections, and finally merged to the master branch after approval. In this way, it becomes integrated into the project.

While it’s not strictly necessary to work on different branches when working alone, it’s an excellent practice to do so. It’s also invaluable training that will get you prepared for the future of working in collaboration with colleagues.

Of course, merging is more involved than just switching, and some conflicts can arise. However, fixing those conflicts is part of the process. The good thing is that no merging is possible until those conflicts are resolved. But that is a fascinating subject in itself and certainly important enough for a future post!

Guillermo Brachetta, Code Institute Graduate

Learn the basics – for free!

If terms like Git Branches are new to you, don’t worry. If you’re new to software development and want to learn some basics, then try our free 5 Day Coding Challenge. After one hour a day over five days, you’ll learn the basics of HTML, CSS and JavaScript. What’s more is, that you will build your first ever webpage. Register now, through the form below.