Welcome to Part 2 of this review of the Pluralsight course “How Git Works” by Paolo Perrotta.

Paolo is a traveling coach and a software mentor. He wrote “Metaprogramming Ruby“, widely praised as one of the essential books on Ruby.

He has hundreds of articles, conference speeches and training deliveries under his belt, and he developed software in domains ranging from automotive to healthcare, large-scale web sites, and computer games.

Also in this series:

Part 1: Git is Not What You Think

Branches Demystified

Introduction

Paolo says even if you use Git branches every day, they might not be what you think they are!

What Branches Really Are

We can view all the branches in our project with the command:

git branch

Paolo shows us the contents of the refs directory. It has a heads subdirectory and in there is our master branch. The only contents of this file is the SHA1. So the takeaway is:

“A branch is just a reference to a commit”

So we can even create or remove branches just by changing the contents in here.

We see that we can create a new branch using the git branch command and that it has the same contents as our master branch. We have a new branch called “lisa”.

The Mechanics of the Current Branch

There is a file in the .git branch called HEAD, and this contains a reference to the file that represents our current branch.

We see that we can use the tree command to see all the files in a tree structure.

Paolo explains what happens to the HEAD when we make a commit. We also see the effect of the git checkout command on the HEAD.

Paolo updates the apple pie recipe in the lisa branch, and commits the change.

Let’s Merge!

We see a conflict when we attempt to merge branches, because we have two different apple pie recipes.

Paolo manually updates the file, compromising on the number of apples.

We see that the file is not staged so we use git add to stage it. This resolves the conflict, and we can complete the merge with git commit. Git creates a suitale commit message for us automatically.

We look at the contents of this commit and see that, unlike the previous commits that we have seen, this has two parents. Paolo says a commit could have as many parents as we want.

Time Travel for Developers

Paolo returns to Commits, trees, and blobs, showing us the earlier diagram and making the point that when we checkout something, Git doesn’t care about history: only about trees and blobs.

He emphasizes that Git content management is simple. He also says Git mostly doesn’t care about your working directory.

He also says we can forget about trees and blobs for the rest of this course. We’ll be focusing on commits and history from here on.

Merging Without Merging

We imagine lisa wants to take the contents of the master branch without keeping her changes.

Git is frugal and hates waste. So it does not add another commit. Instead it just moves the HEAD to the latest commit in master. This is known as a fast forward.

Losing Your HEAD

We can directly checkout a commit, instead of a branch. For example:

git checkout ecbebe6

Now the HEAD points to a commit, instead of a branch. This is known as having a detached HEAD!

We see the effect of making a couple of commits with a detached HEAD, and then checking our master.

We learn that, like modern Object Oriented compilers, Git does garbage collection and may remove these commits to reduce disk space.

If we want to avoid this we can checkout the latest of these commits using its SHA1 hash, and associating it with a branch.

Objects and References

Paolo explains three rules:

1. The current branch tracks new commits
2. When you move to another commit, Git updates your working directory
3. Unreachable objects are garbage collected

And that’s all there is to branches.

The full course also contains modules on “Rebasing Made Simple” and “Distributed Version Control”. I hope to cover these next week. In the meantime, watch them here.