The Git Object Model

At its core, Git is a content-addressable filesystem sitting underneath a version control interface. Everything Git tracks — file contents, directory structure, commit history, and tags — is stored as one of four object types inside the .git/objects database: blobs, trees, commits, and tags. Each object is identified by the SHA-1 (or, in newer repositories, SHA-256) hash of its own content, meaning the object's name is derived entirely from what it contains. This is what makes Git 'content-addressable': two files with identical content anywhere in history, in any branch, produce the exact same hash and are stored only once.

A blob (binary large object) stores the raw contents of a single file — and nothing else. It has no filename, no permissions, no directory location; that metadata lives one level up, in a tree object. Because a blob is identified purely by a hash of its content, if you have ten files across your project with byte-identical content, Git stores that content exactly once and points ten different tree entries at the same blob.

A tree object represents a directory. It lists entries, each pairing a filename, a file mode (permissions, and whether it's a regular file, executable, or symlink), and a pointer to either a blob (for a file) or another tree (for a subdirectory). Trees can nest arbitrarily deep, mirroring your actual directory structure. A commit's snapshot is really just a pointer to one root tree object, which recursively references every file and folder in the project at that moment.

A commit object ties everything together. It points to exactly one root tree (the snapshot), records author and committer name/email/timestamp, includes the commit message, and — critically — points to one or more parent commits (zero parents for the very first commit, two or more for a merge commit). This parent pointer is what forms the commit graph, the directed acyclic structure that git log walks to show you history. Because a commit's hash is computed from its tree, parents, and metadata, changing anything about a commit (even just its message) produces an entirely new hash — this is why 'editing history' in Git always means creating new commit objects, not mutating old ones.

A lightweight tag is simply a named pointer to a commit, similar to a branch but one that (by convention) does not move. An annotated tag is a distinct fourth object type: it has its own hash and stores a tagger, date, message, and optional GPG signature, alongside a pointer to the commit it tags. Annotated tags are preferred for marking releases because they carry this extra metadata and can be cryptographically signed to prove authenticity.