How does Git work internally?

Question

IT Interview Practice · Accepted Answer

Internally, Git is a **content-addressable object store** — it stores everything as **objects** (blobs, trees, commits, tags) identified by their **SHA-1 hash**. Understanding this model demystifies Git and explains why its operations behave as they do.

## Git is a content-addressable object store

```text
Git stores 4 types of OBJECTS, each identified by the SHA-1 HASH of its content:
  BLOB   → file CONTENTS (just the data, no filename)
  TREE   → a directory: maps names → blobs (files) and trees (subdirs) + permissions
  COMMIT → a snapshot: points to a TREE (the root) + parent commit(s) + author/message
  TAG    → an annotated tag object (points to a commit, with metadata)
→ Content-addressable: an object's ID IS the hash of its content (same content = same hash).
```

## A commit is a snapshot, not a diff

```text
→ Each COMMIT points to a complete TREE (the full state of the project at that point)
→ Git stores SNAPSHOTS, not diffs (though it compresses/deduplicates internally):
  unchanged files → the commit's tree just REUSES the same blob (same hash) → efficient
→ Diffs you see are COMPUTED between snapshots, not stored.
```

## How it fits together

```text
Branch (e.g. main) → a pointer (a ref) to a COMMIT
HEAD → points to the current branch (or commit)
Commit → tree → blobs (the snapshot)
Commit → parent → parent → ... (the history chain)
→ Branches/tags are just small files containing a commit hash (cheap pointers).
  That's WHY branching is so lightweight.
```

## Why this explains Git's behavior

```text
✓ Branches are cheap → they're just a 40-char hash in a file (not file copies)
✓ Integrity → content-addressing means corruption/changes are detectable (hash mismatch)
✓ Commits are immutable → changing anything = a new hash = a new commit (why rebase
  creates NEW commits, why history rewriting changes hashes)
✓ Deduplication → identical content stored once (shared blobs)
```

## Why it matters

Understanding how Git works internally is valuable senior-level knowledge because it **demystifies Git** and explains *why* its operations behave as they do, deepening your ability to reason about and use Git confidently.

The core model — Git as a **content-addressable object store** with four object types (blobs for file contents, trees for directories, commits for snapshots, tags) each identified by the **hash of its content** — is the foundation that everything else rests on.

Understanding that **a commit is a snapshot, not a diff** (each commit points to a complete tree representing the full project state, with unchanged files efficiently reusing the same blobs, and diffs computed rather than stored) corrects a common misconception and explains Git's snapshot-based model.

Seeing **how it fits together** (branches and tags as cheap pointers/refs to commits, HEAD pointing to the current branch, commits chained via parents) reveals the elegant simplicity underneath.

Most valuably, this understanding **explains Git's observable behavior**: why **branches are lightweight** (just a hash in a small file, not file copies — explaining why branching is so fast), why Git has **integrity** (content-addressing detects corruption via hash mismatches), why **commits are immutable** and history-rewriting operations like rebase create **new commits with new hashes** (changing any content changes the hash), and why Git **deduplicates** (identical content stored once).

This deeper model transforms Git from a set of memorized commands into an understandable system, enabling confident reasoning about complex operations.

Since understanding the internal object model explains why Git behaves as it does (lightweight branches, immutable commits, hash changes on rewriting, integrity) and elevates one from using Git to truly understanding it, understanding Git internals is valuable senior-level knowledge — a topic that reflects the depth expected for senior roles and provides the mental model to reason about Git confidently, demystifying its behavior and making advanced operations comprehensible rather than mysterious.

Git is a content-addressable object store

A commit is a snapshot, not a diff

How it fits together

Why this explains Git's behavior

Why it matters

Related questions