Figure 4-1 captures how all the pieces fit
together. This diagram shows the state of a repository after a single,
initial commit added two files. Both files are in the top-level
directory. Both the
master branch and a tag named
V1.0 point to the commit with ID
Now, let’s make things a bit more complicated. Let’s leave the original two files as is, adding a new subdirectory with one file in it. The resulting object store looks like Figure 4-2.
As in the previous picture, the new commit has added one
associated tree object to represent the total state of directory and
file structure. In this case, it is the tree object with ID
Since the top-level directory is changed by the addition of the
new subdirectory, the content of the top-level tree
object has changed as well, so Git introduces a new tree,
However, the blobs
feeb1e didn’t change from the first commit to the
second. Git realizes that the IDs haven’t changed and thus can be
directly referenced and shared by the new
Pay attention to the direction of the arrows between commits. The parent commit or commits come earlier in time. Therefore, in Git’s implementation, each commit points back to its parent or parents. Many people get confused because the state of a repository is conventionally portrayed in the opposite direction: as a dataflow from the parent commit to child commits.
In Chapter 6, we extend these pictures to show how the history of a repository is built up and manipulated by various commands.