A Branch is a mechanism that allows for independent development lines within the same project.
A fundamental requirement in any project is the ability to work on different tasks in parallel. For example, adding a new feature, fixing a bug, testing an idea.
We need a mechanism to isolate these changes, without interfering with the main code. In Git, this tool is Branches.
In this entry, we will analyze how Git manages these bifurcations under the hood. We will understand what they are and how they work internally.
Understanding the Commit
To understand how branches work, let’s remember that a commit is an immutable snapshot of your project at a specific moment.
But it also stores the identifier of its parent, which allows “forming a chain” (technically, forming a graph).
What is a branch?
Technically, a branch in Git is a tiny text file (40 bytes) that contains the Hash of a commit. Nothing more.
Think of a branch as a Post-it note with a name, which you stick on top of a specific commit.
When we say we are “on the main branch”, all it means is that there is a pointer named main pointing to the last commit we made.
If we create a new branch called testing, all Git does is create a new label and stick it on the same commit you are on now. It does not copy files.
It does not duplicate code. It only creates a pointer. That’s why it’s an immediate operation.
In other old version control systems, creating a branch meant making a physical copy of all the project files into another folder. It was slow and heavy.
Git manages branches differently. Here creating a branch is instantaneous. It takes the same time whether your project has 3 files or 300,000.
For this reason, don’t be afraid or lazy to create Branches. In Git, branches are used for everything.
The HEAD pointer: “Where am I?”
The HEAD is a special and very important pointer that indicates your current location to Git. It’s the “You are here” marker on Git’s graph 📌.
Imagine you have two branches (main and testing). How does Git know which one you are working on? How does it know that if you make a new commit, it should advance one branch and not the other?
That’s what the HEAD pointer is for. Normally, HEAD does not point to a commit directly, but to a Branch.
This tells Git: “The user is currently working on the Main branch, which in turn points to commit C.”
The movement of pointers
The great thing about this system is how simple and efficient it is. The magic happens with the movement of pointers when we make a new commit.
Imagine we are on main (HEAD points to main). We make changes, git add and finally git commit.
Git creates the new commit D. Its parent will be C.
Since HEAD pointed to main, Git knows “you are on main”. So it has to move the label main to the new commit D.
HEAD still points to main, so no change needs to be made to HEAD (it still follows main).
That is, the main branch has “advanced” automatically. Branches in Git move forward with commits.
You don’t “put code into the branch”, you create commits and the branch (the label) moves to follow you.
Take a breath, and don’t worry if some part seemed difficult. Explaining the basics of branches is not something you understand on the first try.
Keep reading the following articles, and when you have doubts, come back to this one to review the theory. Little by little, you will eventually find it simple.
