How Git stores objects - Mechanics & Internals

Overview - How Git stores objects

What is it?

Git stores data as objects in a special database called the object store. Each object represents a piece of your project, like a file, a folder, or a snapshot of your project at a moment in time. These objects are saved using a unique code called a hash, which helps Git find and verify them quickly. This system lets Git track changes efficiently and safely.

Why it matters

Without Git's object storage system, tracking changes in files and folders would be slow and unreliable. Developers would struggle to manage versions, collaborate, or recover lost work. Git's object storage ensures data integrity, fast access, and efficient storage, making modern software development smooth and dependable.

Where it fits

Before learning how Git stores objects, you should understand basic Git concepts like commits, branches, and repositories. After this, you can explore how Git uses these objects to build history, manage branches, and perform operations like merging and rebasing.

Mental Model

Core Idea

Git stores every piece of your project as a uniquely identified object in a content-addressable database to track changes efficiently and securely.

Think of it like...

Imagine a library where every book is given a unique barcode based on its content. Instead of searching by title or author, you scan the barcode to find the exact book. Git’s objects are like these barcoded books, ensuring you always get the exact content you need.

┌───────────────┐
│ Git Object DB │
├───────────────┤
│ Blob (file)   │
│ Tree (folder) │
│ Commit       │
│ Tag          │
└─────┬─────────┘
      │
      ▼
  Unique SHA-1 Hash
      │
      ▼
  Content stored compressed and checksummed

Build-Up - 7 Steps

1

Foundation

Git objects basics

Concept: Git stores data as objects of four types: blobs, trees, commits, and tags.

Git breaks down your project into four object types: - Blob: stores file content. - Tree: stores folder structure and references blobs or other trees. - Commit: stores a snapshot of the project, pointing to a tree and parent commits. - Tag: marks a specific commit with a name. Each object is stored in a compressed form and identified by a SHA-1 hash.

Result

You understand the four core object types Git uses to represent your project data.

Knowing these object types helps you see how Git models your project as a set of connected data pieces, not just files.

2

Foundation

Content-addressable storage explained

Concept: Git uses the content of an object to create a unique hash that identifies it.

When Git stores an object, it first creates a header with the object type and size, then appends the content. It calculates a SHA-1 hash of this combined data. This hash acts like a fingerprint, uniquely identifying the object by its content. If the content changes, the hash changes too.

Result

You see how Git ensures data integrity and uniqueness by hashing content.

Understanding content-addressable storage explains why Git can detect changes and avoid duplicates efficiently.

3

Intermediate

Object storage on disk

Concept: Git stores objects as compressed files in a specific directory structure on disk.

Git saves each object as a compressed file inside the .git/objects directory. The first two characters of the hash form a folder name, and the remaining characters form the file name. For example, an object with hash 'e68...' is stored in '.git/objects/e6/8...'. This structure avoids too many files in one folder and speeds up access.

Result

You can locate and identify Git objects on your computer’s file system.

Knowing the storage layout helps you understand Git’s performance and how it manages millions of objects.

4

Intermediate

Packfiles for efficiency

🤔Before reading on: do you think Git stores all objects as separate files or combines them? Commit to your answer.

Concept: Git combines many objects into packfiles to save space and speed up operations.

As projects grow, storing each object as a separate file becomes slow and space-consuming. Git solves this by packing multiple objects into a single file called a packfile. Packfiles store objects efficiently by compressing shared data and using delta encoding, which stores only differences between similar objects.

Result

You understand how Git optimizes storage and speeds up cloning and fetching.

Recognizing packfiles reveals how Git scales to large projects without slowing down.

5

Intermediate

Object referencing and linking

🤔Before reading on: do you think commits store file data directly or reference other objects? Commit to your answer.

Concept: Git objects reference each other to build the project history and structure.

Commits point to a tree object representing the project snapshot. Trees point to blobs (files) or other trees (folders). Commits also reference parent commits to form history. This linking creates a graph of objects that Git uses to track changes over time.

Result

You see how Git builds a connected structure of objects representing your project and its history.

Understanding object linking explains how Git reconstructs any project state efficiently.

6

Advanced

Object hashing and collision resistance

🤔Before reading on: do you think SHA-1 hashes can never collide or collisions are possible but rare? Commit to your answer.

Concept: Git relies on SHA-1 hashes for object identity but has mechanisms to handle rare collisions.

SHA-1 produces a 40-character hash from object content. While collisions (two different contents producing the same hash) are extremely rare, Git is designed to detect and handle them if they occur. Newer Git versions support SHA-256 for stronger security. This hashing ensures data integrity and trustworthiness.

Result

You appreciate the security and reliability of Git’s object identification.

Knowing about hash collisions prepares you for understanding Git’s evolving security measures.

7

Expert

Delta compression in packfiles

🤔Before reading on: do you think Git stores full copies of similar files in packfiles or only differences? Commit to your answer.

Concept: Git uses delta compression to store only differences between similar objects inside packfiles.

When Git creates packfiles, it looks for similar objects and stores one full copy plus small differences (deltas) for others. This reduces storage size drastically. Delta chains can be long, but Git balances compression and access speed. This technique is key for handling large repositories with many similar files or versions.

Result

You understand how Git achieves high compression without losing fast access.

Understanding delta compression reveals the clever trade-offs Git makes between space and speed.

Under the Hood

Git stores objects by first creating a header with the object type and size, then appending the raw content. It computes a SHA-1 hash of this combined data, which acts as the object's unique ID. Objects are compressed using zlib and saved in a directory structure based on the hash. Over time, Git packs many objects into packfiles using delta compression to save space. Commits reference trees, which reference blobs and other trees, forming a directed acyclic graph representing project history.

Why designed this way?

Git was designed to be fast, reliable, and space-efficient for version control. Using content-addressable storage with hashes ensures data integrity and easy detection of changes. The directory structure avoids filesystem limits on file counts. Packfiles and delta compression address scaling issues as projects grow. Alternatives like storing full copies or using timestamps were slower or less reliable, so Git’s design balances speed, safety, and storage.

┌───────────────┐
│ User files    │
└──────┬────────┘
       │ git add (creates blobs)
       ▼
┌───────────────┐
│ Blob objects  │
└──────┬────────┘
       │ referenced by
       ▼
┌───────────────┐
│ Tree objects  │
└──────┬────────┘
       │ referenced by
       ▼
┌───────────────┐
│ Commit object │
└──────┬────────┘
       │ stored as
       ▼
┌───────────────┐
│ Object store  │
│ (.git/objects)│
└───────────────┘
       │
       ▼
┌───────────────┐
│ Packfiles     │
│ (compressed)  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think Git stores full copies of every file version separately? Commit yes or no.

Common Belief: Git stores a full copy of every file each time you commit.

Reality: Git stores file contents as blobs and uses trees and commits to reference them. It avoids duplicate storage by hashing content and uses delta compression in packfiles to save space.

Why it matters: Believing Git stores full copies leads to misunderstanding its efficiency and can cause confusion about repository size and performance.

Quick: Do you think the SHA-1 hash in Git is just a random ID? Commit yes or no.

Common Belief: The SHA-1 hash is just a random identifier assigned to objects.

Reality: The SHA-1 hash is a cryptographic fingerprint calculated from the object's content and header, ensuring uniqueness and integrity.

Why it matters: Misunderstanding the hash's role can lead to ignoring data corruption risks or the importance of content integrity.

Quick: Do you think packfiles store objects uncompressed? Commit yes or no.

Common Belief: Packfiles store objects as-is without compression.

Reality: Packfiles compress objects and use delta compression to store only differences between similar objects.

Why it matters: Ignoring compression leads to underestimating Git's storage efficiency and performance optimizations.

Quick: Do you think commits store file data directly? Commit yes or no.

Common Belief: Commits contain the actual file contents of the project snapshot.

Reality: Commits store metadata and reference a tree object, which in turn references blobs (file contents) and other trees (folders).

Why it matters: This misconception can confuse how Git reconstructs project states and manages history.

Expert Zone

1

Git’s object storage design allows for efficient garbage collection by identifying unreachable objects through the commit graph.

2

Delta compression chains in packfiles are carefully balanced to optimize between compression ratio and access speed, which can be tuned by Git’s configuration.

3

Git’s transition from SHA-1 to SHA-256 is designed to be backward compatible, allowing repositories to gradually upgrade without breaking existing data.

When NOT to use

Git’s object storage is optimized for source code and text files. For large binary files or datasets, specialized tools like Git LFS or external storage systems are better suited to avoid performance degradation.

Production Patterns

In production, Git repositories often use packfiles aggressively to reduce size and improve clone/fetch speed. Continuous integration systems rely on Git’s object model to quickly check out specific commits. Advanced workflows use shallow clones and partial fetches to limit object transfer.

Connections

Content-addressable storage (CAS)

Git’s object storage is a practical implementation of CAS principles.

Understanding CAS in distributed storage systems helps grasp how Git ensures data integrity and deduplication.

Hash functions in cryptography

Git uses cryptographic hash functions to identify objects uniquely and securely.

Knowing how hash functions work explains Git’s resistance to data corruption and tampering.

Database indexing

Git’s object store and packfiles act like an index for fast data retrieval.

Recognizing Git’s storage as an indexing system clarifies how it achieves quick access to project history.

Common Pitfalls

#1 Trying to manually edit files inside .git/objects directory.

Wrong approach:

echo 'change' > .git/objects/e6/8f3a... (editing object files directly)

Correct approach:

Use Git commands like git add, git commit to modify repository content safely.

Root cause:

Misunderstanding that Git objects are compressed and hashed data, not plain files.

#2 Deleting loose object files to save space without packing.

Wrong approach:

rm .git/objects/e6/8f3a... (removing object files manually)

Correct approach:

Run git gc to safely clean and pack objects.

Root cause:

Not knowing Git’s internal storage and garbage collection mechanisms.

#3 Assuming SHA-1 hashes are collision-proof and ignoring security updates.

Wrong approach:

Ignoring Git warnings about SHA-1 vulnerabilities and not upgrading.

Correct approach:

Upgrade Git to versions supporting SHA-256 and migrate repositories accordingly.

Root cause:

Lack of awareness about cryptographic hash weaknesses and Git’s evolving security.

Key Takeaways

Git stores project data as objects identified by hashes, ensuring integrity and uniqueness.

Objects include blobs for files, trees for folders, commits for snapshots, and tags for references.

Git uses a content-addressable storage system that compresses and organizes objects efficiently on disk.

Packfiles and delta compression allow Git to scale to large projects without performance loss.

Understanding Git’s object storage reveals the foundation of its speed, reliability, and powerful version control features.