paint-brush
Git Does Not Have Branchesby@omri.spector
790 reads
790 reads

Git Does Not Have Branches

by Omri SpectorMay 28th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Okay, this is not another git rant. Git has taken the world by storm, and anyone <a href="https://hackernoon.com/tagged/complaining" target="_blank">complaining</a> should go sit in a corner, and stop wasting our time.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Git Does Not Have Branches
Omri Spector HackerNoon profile picture

Okay, this is not another git rant. Git has taken the world by storm, and anyone complaining should go sit in a corner, and stop wasting our time.

This post is an explanation of the most important quirk in git terminology and how it affects everything you do in version control. You see, while “branch” is a central keyword in git — git in fact does not have branches.

Let’s start at the beginning. What is a branch?

A version control system tracks our development as a set of change sets, gradual steps that lead from “Version A” to “Version B”.

But in the real world, things are not always linear. Sometimes we start at one point, but “branch” in two directions. It may be because we are developing two features in parallel (i.e. “feature branches”) or because we want to introduce a fix to an old version (“fix branch”). The effect is the same -we now have parallel development tracks. In the pre-git world we called these “branches”

A branch is a code change path

Turns out that git does NOT call the path “a branch”. In fact, git does not even save the fact that this path was created for a purpose (“To fix bug 123”) anywhere.

In git-speak, a branch is just a pointer to the head of a code change path. A place where you can commit more changes if you would like.

A git branch is just a pointer. no path data is included.

Why does this matter?

It means that git does not store the rationale of branching, the reason for why we branched in the first place. This can be very confusing:

Diamond: Was change X part of “fix A” or of “feature B”?

And this is not a rare scenario. It actually happens every time you merge code from on branch to another. Looking at the history of an actual git repo exemplifies this pretty well:

This isn’t a map of the metro

And what is the lesson of this? When branching in git, you should maintain a consistent practice and not be “overly creative”.

Because git does not have branches, it has pointers that somehow got the wrong name. Branching in git is very simple, but always keep in mind that the cost of a new branch is not the complexity of opening the branch — it is risking your ability to understand the motives behind changes in hindsight.

There are several branching strategies, and each has it’s pros and cons. Stick to one and you should be fine.