Previously, in part 1, we went over the core of Git and why it gives us a fighting chance when merging sets of changes. Let’s continue by starting off with branches.
The Branch
So, where is your current work in the Git graph? It could be anywhere. Since every commit could have as many children as you want, you could go back to a commit in the center and spin off a new idea. A Branch in Git is another name for a pointer to a location inside the Git graph. Let me update the picture.
There are a couple of things to notice here. First, the teal branches indicate where the current work is going on. You can see the first one is called ‘master.’ This is a default branch that is created with every Git repository and is usually considered the most up to date and trustworthy branch. It is worth noting that there is no difference between each branch, other than their name and what commit they are pointing to. Nothing is inherently special about the master branch. You can have as many branches as you want. You can also see a commit, which I have highlighted in red. It has no branch pointing to it or its children. This is an orphaned commit. It still exists in the database and you can get to it if you know what its hash is. If you prune the Git database, this commit will disappear. Just for reference, we are still talking about items that exist inside the Git database and not on the file system.
The HEAD
We need to discuss one more concept before we can finally move outside of the Git database. We need the HEAD (yes, it is in all caps). The HEAD is a reference to what commit is currently showing in your source tree. It can be pointing to a specific commit or a branch. If it is pointing to a specific commit, then you will enter the very confusingly named “Headless Mode.” This means that your HEAD is not pointing to a branch, not that you don’t have a HEAD. You always have a HEAD. “Headless Mode” is dangerous because any commit you make in “Headless Mode” is guaranteed to be an orphan, as Git has no idea what branch you want to apply to the new commit. The normal Git workflow is outside of “Headless Mode.” In this mode, if you make a commit, the branch that is associated with HEAD is moved to the new commit. Below is an image depicting a HEAD that is pointing to the “feature2” branch. Notice that the content of your working directory is the commit that is colored orange.
This concludes part 2. Stay tuned for the next part, where I talk about Remotes and how to get your code to others.
