Inside Git: How It Works and the Role of the .git Folder:

Vikash Kumar — Fri, 16 Jan 2026 04:25:49 GMT

When I first learned Git, I only memorized commands like git init and git commit.
They worked, but I didn’t really understand what Git was doing behind the scenes.

So I decided to look inside Git itself — especially the mysterious .git folder.
That completely changed how I understand Git.

This blog explains how Git works internally, in simple words, without heavy theory.

How Git Works Internally (Big Picture):

Git: It is an open-source version control tool that is used by programmers for controlling versions of their codebase and collaborate with others. You can install your own Git server on your server. Most cloud providers also give it.

Instead of saving file differences line by line, Git:

Takes snapshots of your project
Stores them efficiently
Connects them together using history

Everything Git does is powered by what’s inside the .git folder.

Understanding the .git Folder

When we run:

git init

Git creates a hidden folder called .git folder.

This folder is brain of Git.

If this folder is deleted, Git forgets everything about the project.

Why the .git folder exists:

To store project history
To store commits
To track branches and HEAD
To ensure data integrity

Your actual code lives outside .git,
but Git’s memory lives inside .git folder.

Inside .git**, some important parts are:**

objects/ → stores all Git data
refs/ → stores branch pointers
HEAD → points to current branch
index → staging area data

You usually never edit these files manually — Git handles them for you.

Git Objects: Blob, Tree, and Commit:

Git stores everything as objects.
There are only three main object types, and understanding them builds a strong mental model.

1. Blob (File Content):

A blob stores the content of a file.

Important thing I learned:

Blob does not store file name.
Blob only stores file data.

If two files have the same content, Git stores only one blob.

Question: How to store only one blob?

Answer:

If two files have exactly the same content, Git calculates the same hash for both and stores only one blob.
Both files then simply point to that same blob, which helps Git save space and work efficiently.

2. Tree (Folder Structure)

A tree represents a directory.

It stores:

File names.
Folder structure.
Links to blobs and other trees.

Tree objects tell Git how files are organized.

3. Commit (Snapshot)

A commit connects everything.

A commit contains:

A reference to a tree
Parent commit(s)
Author and message
Timestamp

If I talk to in simple words:

A commit = snapshot + history + message.

Relationship Between Commit, Tree, and Blob

Mental model I use: The chain of command

you can visualise the relationship as a hierarchy or a “chain of pointers” They do not talk to each other directly. they need a middleman called a Tree.

Git internally works using three main object types:

Blob → file content.
Tree → folder structure.
Commit → snapshot + history.

Each object has a specific role, and together they form Git’s core design.

Blob: The Actual File Content

A blob stores the content of a file, nothing else.

Important things about blobs:

A blob does not store file names
A blob does not store folder paths
It only stores raw data (text or binary)

If two files have the same content, Git creates only one blob and both files point to it.
This is how Git saves space and avoids duplication.

Tree: The Folder Structure

A tree represents a directory (folder).

A tree object stores:

File names.
Folder names.
Permissions.
Links to blobs and other trees.

Think of a tree as a map that tells Git:

Which files exist.
Where they are located.
Which blob belongs to which file name.

Commit: The Snapshot and History

A commit is the top-level object.

A commit stores:

A reference to one tree (root directory).
Reference to parent commit(s).
Author information.
Commit message.
Timestamp.

A commit does not store files directly.
It simply points to a tree, which then points to blobs.

How They Work Together (Step by Step)

When I make changes and commit:

Git creates blobs for file contents
Git creates trees to describe folder structure
Git creates a commit pointing to the root tree
Git links the commit to previous commit(s)

So internally, Git looks like this:

The connection:

Why Git Uses This Design

This design gives Git several advantages:

1. Efficiency

Same content = same blob
No unnecessary duplication

2. Safety

Nothing is overwritten
Old data stays safe as long as it’s referenced

3. Speed

Git only creates new objects when content changes
Unchanged parts are reused

4. Strong History

Commits form a linked timeline
Every snapshot is preserved

Real-World Example

Suppose I change only one file in a project with 100 files.

Git will:

Create one new blob (for the changed file)
Reuse existing blobs for unchanged files
Create a new tree and commit

So Git is not copying the whole project again — it’s being smart.

The Mental Model That Clicked for Me

Instead of thinking:
“Git saves files”

I think:
“Git stores objects and links them”

Blobs store data
Trees organize data
Commits record snapshots

Once I understood this, Git commands stopped feeling random.

Final Thought

Git is not magic.
It’s a content-addressed database with a brilliant design.

If you understand how commit → tree → blob works.

How Git Tracks Changes

When I first started using Git, I thought it tracked files the same way my computer does by name and location.
But Git actually works in a much smarter way.

Git tracks changes in content, not just files.

Git Tracks Content, Not File Names

Every time I change a file, Git looks at what changed inside the file, not the file name itself.
If the content is different, Git treats it as a new version.

If two files have exactly the same content, Git stores that content only once and simply points both files to it.
This makes Git efficient and avoids duplication.

The Role of the .git Folder

All of Git’s tracking logic lives inside a hidden folder called .git.

This folder exists to:

Store the complete history of the project
Keep records of commits and branches
Track changes safely and reliably

What Happens When I use git add

When I run git add, Git does not save a version immediately.
Instead, it prepares the changes.

Internally:

Git reads the file content
Converts it into a blob object
Stores it inside the .git folder
Marks it as ready in the staging area

This step allows me to carefully choose what should go into the next version.

What Happens When I Use git commit

When I run git commit, Git creates a permanent snapshot.