Welcome to Part 2 of this review of the Pluralsight course “How Git Works” by Paolo Perrotta.
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:
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.
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:
- The current branch tracks new commits
- When you move to another commit, Git updates your working directory
- 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.