Git is an ubiquitous tool in software engineering, but it is difficult to find an introduction to the mental model behind Git. Git users often repeat a set of memorized commands that work for some situations, resorting to colleagues when the cheat sheet fails.
Having understood Git’s conceptual model, I am able to use the tool more effectively than before, employing it in ways that I didn’t know were possible: by framing a problem as an operation on the commit history graph, I can find the Git command I need to solve it.
In this post, we’ll go over Git’s conceptual model without mentioning a single command-line operation. Once the model is clear, then we look at daily actions performed by developers and map those actions to Git concepts.
A version control system is a program that keeps track of the state of a repository as it evolves through time. It allows us to go back and forth between states, to record new states, and to inspect the history of the repository.
In Git, saving a new state of the repository consists of:
The staging area consists of a set of changes that will be included by the next commit operation. It partitions the repository into three categories of files:
During development, we are editing files, staging changes, and finally doing a commit operation:
Nothing stops us from editing a file, staging it and editing the file again; this effectively creates a new kind of file that has both staged and unstaged changes. It’s up to us to decide what we want the next commit to include: if it should include the new changes, then we have to stage them too.
Git also allows us to stage some of the changes in a file, in fact the mental model is that we stage changes done to a file, not the file itself. Staging only a subset of the changes done to a file is helpful in case they don’t all logically belong on the same commit.
So what is a commit operation?
It is the act of taking a snapshot of the entire repository is taken and storing it into an internal data structure. A commit operation creates a commit object, which consists of:
By pointer we mean a hash of the object; it is common to refer to a commit by its hash.
Note: if any of the items above is changed, the commit hash will change too!
Unfortunately, the verb “commit” and the noun “commit” are the spelled the same way in English; when we use it as a verb, we mean the act of performing a commit operation, whereas the noun refers to the commit object (or its hash).
Because a commit stores a reference to the preceding commit, in other other words, because a commit has a parent, the repository can be represented as a directed acyclic graph: nodes are commits and a directed edge
(commit2, commit1) indicates that commit
commit1 is a parent of
For ease of representation, I’m using names for the commits in the pictures, but
commit2 actually represent the hash of the respective commits.
The concept of a branch is what allows us to navigate through important states of a repository. A branch in Git is a pair
(name, pointer to a commit).
In this example, we have two branches named
master, both pointing to commit
commit1, and a branch named
feature2 pointing to
Note: there is nothing special about the branch named
master. When you create a repository from scratch, you need a name for the starting branch –
master is the default and few repositories bother renaming it.
Since we’re jumping around the history of the repository all the time, how do we know which snapshot we’re looking at? This information is tracked by a special pointer called
HEAD. Most of the time,
HEAD points to a branch:
In this example, we are looking at the repository as defined by branch
feature2, which points to
When we add a new commit, we advance the branch pointed by the