Understanding Git branches
Tags: git, development
Published: 2023-06-15 20:28:47




In the [last](https://dev.to/ag2byte/what-actually-happens-when-you-git-36nf) article we talked about internal working of Git. We saw the actual meaning of git commits and how git uses them to track different versions of stuff in the repository. 

One of the biggest things git offers is the ability to create branches. These are separate parallel paths carrying different versions of the repository, at times independent from each other. In this article we will look at what actually happens when you use branches. 

### A new branch

So far we have only had one branch,i.e, `master`. Go ahead and create a new branch using
```
> git branch canon
> git checkout canon
```

If we check the `.git` folder now, we have a new file called `canon` in refs

![canon in refs](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q7o8ee21ru2kunlt6vkz.jpg)
The `refs` folder basically tracks the different references throughout the repository. The `HEAD` file contains the path to this `canon` file as well. Now let's check the contents of the `canon` file. 

![cat canon](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1du1d1wtd635or0fbmc9.jpg)

We can see that this is the most recent commit in the `canon` branch. Thus the repository tree looks something like this.

![branch structure 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l44x09vedn7u73q31j3z.jpg)

### New branch moves forward

Lets make some changes in `testfile` in the `canon` branch and commit it. We now have three new files in the `objects` folder

![new files](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9elzl7qn82w831ru7tt7.jpg)

Using `git cat-file`, we can deduce the relations between each of these files


![git cat-file](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i0k7zho20pmhnsw45jhk.jpg)

This is similar to what we saw in the last article, `5d...` is the commit, `51...` is the tree originating from the previous commit(`f5...`) and `23...` is the blob where the actual content is present. The repository looks something like this.

![new tree](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l332xppouqzaptj854np.jpg)

Notice that the `objects` folder only contains this information and not the information of which branch this is on. That is maintained by the `HEAD` file. Since the `HEAD` points to the `canon` and that contains the new commit, the `HEAD` now points to the latest commit in `canon`.

![canon cat-file](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gw5mcjnbl5siyksljpqv.jpg)

### Merging the new branch

Let's merge the new branch in the master branch 
```
❯ git checkout master
❯ git merge canon
```

![New merge](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/95su1876foc1hcuze8mv.jpg)

Now if we check the contents of `master` in refs, we get `5d6808021c9dfd7bbe88fb8ac450e572982f79b7`, which is the latest commit that is merged from the new branch. Thus the repository looks something like this: 

![new tree](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d80wdser3tiumicthxxi.jpg)

Thus we can see how git maintains the reference of the branches along with the contents of it. This is what makes git so powerful. Having a tree structure means git can navigate to any specific commit in any specific branch. 

Thanks for reading!