Committing History

What

A repository’s history is not just a loose list of independent commit snapshots. Instead, Git builds an unbroken timeline of changes by linking each new commit directly to its predecessor using a parent property.

How

When you inspect the very first commit (the “root commit”) of a repository, it has no history before it:

# First commit object content
git cat-file -p <first_commit_hash>
# Output:
# tree 4e507fd...
# author ...
# committer ...
# (No parent field is present!)

However, if you make a second commit and pretty-print it, you will notice an extra field named parent containing the hash of the first commit:

# Second commit object content
git cat-file -p <second_commit_hash>
# Output:
# tree 8f2a1b9...
# parent 5ba786fcc93e8092831c01e71444b9baa2228a4f  <-- Pointer to first commit
# author ...
# committer ...

Why

Storing parent pointers inside commit objects forms a Directed Acyclic Graph (DAG). This structural chain is what allows Git to construct a reliable, chronological history of your code. By starting at the latest commit (referred to as HEAD) and following parent pointers backward, Git can reconstruct every single state of your repository all the way back to the root commit.

Summary

Every commit (except the initial root commit) contains a parent field pointing to the hash of the commit that came before it, creating a chronological chain of history.