Back to Articles

Behind the Scenes: How Git Works Under the Hood

Behind the Scenes: How Git Works Under the Hood
Behind the Scenes: How Git Works Under the Hood

Introduction

Git is one of the most widely used version control systems in the world, powering everything from small personal projects to massive open-source collaborations like the Linux kernel. While many developers use Git daily, few truly understand how it works behind the scenes.

In this in-depth guide, we'll explore Git's internal architecture, how it stores data, and the mechanisms that make version control efficient and reliable. By the end, you'll have a solid understanding of Git's core concepts, allowing you to use it more effectively and troubleshoot issues with confidence.

Table of Contents

1. What is Git?

A Brief History

Git was created in 2005 by Linus Torvalds, the creator of Linux, after a licensing dispute with BitKeeper, the version control system used for Linux kernel development at the time. Torvalds designed Git with three key goals in mind:

  • Speed – Fast operations even on large codebases.
  • Distributed Model – Every developer has a full repository history.
  • Integrity – Strong safeguards against data corruption.

Why Git is Different

Unlike centralized version control systems (e.g., SVN), Git is distributed, meaning every developer has a full copy of the repository, including its entire history. This allows offline work and reduces reliance on a central server.

Git also differs in how it stores data. Instead of tracking file changes as deltas (like SVN), Git takes snapshots of the entire file system at each commit, making operations like branching and merging extremely efficient.

2. Git's Internal Architecture

Git operates using three main areas:

  1. The Git Directory (Repository) – Where Git stores all metadata and object databases.
  2. The Working Directory – The local files you edit.
  3. The Staging Area (Index) – A temporary area where changes are prepared before committing.

The Git Directory (.git folder)

This is where Git stores everything it needs to manage the repository:

  • Objects database (blobs, trees, commits, tags)
  • Refs (branches, tags, remote tracking)
  • HEAD pointer (current branch/commit)
  • Configuration files (config, hooks, etc.)

The Working Directory

This is your project's file system. When you modify files, Git detects changes between the working directory and the staging area.

The Staging Area (Index)

Before committing, changes must be staged using git add. The staging area acts as a checkpoint, allowing selective commits.

3. How Git Stores Data

Objects: Blobs, Trees, Commits, and Tags

Git's data model is built around four key objects:

  1. Blob – Stores file contents (binary data).
  2. Tree – Represents directories, listing blobs and subtrees.
  3. Commit – Points to a tree (snapshot), contains author info, and links to parent commits.
  4. Tag – A named reference to a commit (used for releases).

The Hashing Mechanism (SHA-1)

Every object in Git is identified by a unique 40-character SHA-1 hash, computed from its content. This ensures:

  • Data integrity (any change alters the hash).
  • Efficient storage (duplicate files share the same blob).

The Object Database

All objects are stored in .git/objects/:

  • First two characters → Directory name.
  • Remaining 38 → Filename.

Example: a1b2c3... → .git/objects/a1/b2c3...

Packfiles and Compression

Over time, Git compresses objects into packfiles to save space. The git gc (garbage collection) command handles this.

4. Branching and Merging Internals

What is a Branch?

A branch is just a pointer to a commit. Creating a branch (git branch feature) adds a new ref in .git/refs/heads/.

How Git Handles Merges

  • Fast-forward merge – If no diverging history, HEAD moves forward.
  • Three-way merge – Combines changes from two branches using a common ancestor.

Conflict Resolution

When Git can't auto-merge, it marks conflicts in files, requiring manual resolution.

5. The Role of the HEAD Pointer

  • HEAD points to the current commit (usually via a branch).
  • Detached HEAD occurs when you checkout a commit directly (not a branch).

6. The Refs: Branches and Tags

  • Branches are mutable refs that move with new commits.
  • Tags are immutable (lightweight tags are just refs, annotated tags are full objects).

7. The Git Workflow Explained

  1. Modify files in working directory.
  2. git add stages changes in the index.
  3. git commit creates a new commit object from the index.

8. Networking in Git

  • git clone downloads the entire repository.
  • git fetch retrieves remote changes.
  • git push uploads local commits.

9. Git's Garbage Collection

  • Removes unreachable objects.
  • Runs automatically (git gc).

10. Common Git Internals Misconceptions

Myth: Git stores diffs.

Reality: Git stores snapshots.

Myth: Deleting a branch deletes commits.

Reality: Only the branch pointer is removed; commits remain until garbage collected.

11. Advanced Git Internals

  • Reflog – Logs all reference changes (git reflog helps recover lost commits).
  • Reset vs. Rebase – reset moves HEAD, rebase rewrites history.

12. Conclusion

Understanding Git's internals makes you a more effective developer. You'll debug issues faster, use advanced commands confidently, and appreciate Git's elegant design.

Further Learning Resources