Git stores snapshots, not changesets, using a content-addressable file system with four object types: 1. Blobs store file content without metadata, identified by the SHA-1 hash of the content; 2. Trees represent directories, containing references to blobs and subtrees with file modes and names; 3. Commits point to a root tree and include metadata like author, timestamp, message, and parent commits, forming a history chain; 4. Tags are named, often signed, references to objects, typically commits, for marking versions. Branches are movable pointers to commits stored in .git/refs/heads/, automatically updated on commit, while tags remain fixed. Each object is stored under its SHA-1 hash in .git/objects/, ensuring deduplication and integrity. When committing, Git hashes files in the index as blobs, builds directory trees, creates a commit pointing to the root tree and parent, and updates the branch reference. The commit history forms a directed acyclic graph (DAG) via parent links. All objects are immutable, and Git uses compression to stay efficient. Understanding this model clarifies commands like git rebase, git reset, and git reflog as operations that manipulate pointers or create new objects, revealing Git’s core as a system of hashes, trees, and chains for versioning files.

Git’s internal data model is simpler than most people think — once you understand the core ideas. At its heart, Git is a content-addressable file system with a few higher-level tools to manage versioned code. It doesn’t store changesets like traditional VCS tools; instead, it stores snapshots of your entire project at different points in time. Let’s break down how this works.

The Four Main Object Types

Git uses four types of objects internally: blobs, trees, commits, and tags. All of these are stored in .git/objects/ and are identified by their SHA-1 hash.

1. Blobs (Binary Large Objects)

• Represents the content of a file.
• Does not store filenames, permissions, or metadata — just raw file content.
• Example: If you have a file hello.txt with content "Hello, world!", Git creates a blob object for that content.
• The key is the SHA-1 hash of the content:
  echo -n "Hello, world!" | git hash-object --stdin → gives you the blob’s ID.

2. Trees

• Acts like a directory — it stores references to blobs and other trees (subdirectories).
• Contains a list of entries: file mode, object type, filename, and SHA-1 of the blob/tree.
• Trees represent the structure of your project at a point in time.
• You can think of a tree as a snapshot of a directory.

3. Commits

• Points to a single tree (the root directory of your project at that moment).
• Contains metadata: author, committer, timestamp, log message, and crucially — zero or more parent commits.
• This is what creates the history chain.
• A commit with one parent is a normal commit; two parents means a merge.

4. Tags

• A named reference to another object (usually a commit).
• Used to mark specific points in history (e.g., v1.0.0).
• Can be signed for authenticity.

How Git Builds History: The Commit Chain

When you make a commit:

1. Git takes the current state of your staging area (index).
2. Creates blobs for each file.
3. Builds a tree (or nested trees) representing the directory structure.
4. Creates a commit object pointing to that root tree.
5. The commit also references its parent(s) — the previous commit(s).

Because each commit points back to its parent, Git forms a directed acyclic graph (DAG) of history.

Example:

A ← B ← C ← D

Each letter is a commit. D points to C, C to B, and so on. The chain is built via the parent field in commit objects.

References: Branches and Tags

Git uses references (refs) to make it easier to refer to commits.

• Branches are just pointers to a commit.
  git branch feature creates a file .git/refs/heads/feature containing a commit hash.
• When you commit, the branch reference automatically moves forward.
• HEAD is a special pointer that says which branch (or commit) you’re on.

Tags are also refs but usually don’t move — they’re fixed labels.

Content-Addressable Storage: Everything is Named by Hash

Every object is stored under a filename that is the SHA-1 hash of its content:

.git/objects/de/adbabe12...  → a blob, tree, or commit

This means:

• Identical content → same hash → stored only once (deduplication).
• Any change in content → completely different hash.
• Tampering is detectable — the hash would change.

You can inspect objects using:

git cat-file -p <hash>

What Happens When You Commit?

Here’s a simplified view:

1. Files in the index are hashed and stored as blobs.
2. Git builds a tree for each directory, referencing blobs and subtrees.
3. A commit object is created pointing to the root tree and parent commit.
4. The current branch reference is updated to point to this new commit.

No deltas — just snapshots. Even though it sounds inefficient, Git uses compression and packing (via git gc) to stay lean.

Key Takeaways

• Git stores snapshots, not diffs.
• Everything is immutable — once created, objects never change.
• The SHA-1 hash acts as a unique ID and integrity check.
• Branches are just moveable pointers to commits.
• The history is a graph built from commit parent links.

Understanding this model helps demystify commands like git rebase, git reset, and git reflog, because you realize they’re just moving pointers or creating new objects.

Basically, Git is a smart way to version files using hashes, trees, and chains. Once you see it, it clicks.

The above is the detailed content of Understanding Git's Internal Data Model. For more information, please follow other related articles on the PHP Chinese website!