A Couple of days ago I wrote about Tom Preston-Werner‘s talk on Git and how he approached the subject matter in a particularly effective way. Today, I was trawling through his Web site and found a longish post entitle The Git Parable that serves as a nice companion piece to the talk.
In the post he helps us understand the concepts behind Git by asking us to imagine that we are a developer with no VCS of any kind on our system. Because we are conscientious developers, we realize that we need to implement some method of keeping track of the versions of a large program that we are developing. The rest of the post is a parable about how we build a Git-like system from the ground up.
We start by realizing that what we want is to be able to take snapshots of our code as we implement each feature and save these snapshots so that we can recreate the software as it was at the time of any snapshot. Our first solution is to copy the working directory into another directory and name it snapshot-0. We do this for each snapshot but change the name so that we have a series of directories named snapshot-0, snapshot-1, snapshot-2 and so on. With each snapshot we add an extra file that contains a summary of the changes in the snapshot. We call it the description file.
Everything is fine until the first release. As we start on the next release we suddenly start getting bug reports so we fix those starting from the snapshot of the first release. But now we lose the implicit ordering of the snapshots because the bug fix is the child of the release snapshot, not the latest snapshot that we are currently working on. This introduces the idea of branches and causes us to explicitly record the parent of each snapshot in the description file.
The parable goes on to describe how new situations cause us to add new features to our system. For example, we take on a co-developer and now we suddenly have two different snapshots with the same name. We solve that by replacing snapshot-n with the SHA1 of the snapshot’s contents. By the end of the parable, we have built a system that looks pretty much like Git.
This is an excellent way of introducing Git because
- It shows the simplicity of the ideas behind Git.
- We can see how each feature is there to solve a real world problem.
- Understanding the concepts behind Git’s internals makes it much easier to learn the system and feel confident in using it.
Unless you are a Git expert, I urge you to read this post. If you have colleagues that are new to Git, this parable will be a real help for them in understanding and learning the system.