How Git Works Internally

When we start learning Git, we usually memorize commands like git add, git commit, and git push.
But deep inside, we still feel confused:

“What is Git actually doing behind the scenes?”

This article is my attempt to explain how Git works internally, in simple language, without scary theory.
If you understand this, Git will stop feeling like magic and start feeling logical.

First Things First: What is the .git Folder?

Whenever you run:

git init

Git creates a hidden folder called .git.

👉 This .git folder is Git itself.
Your project files are just normal files.
All Git intelligence lives inside .git.

If you delete the .git folder:

• Your code stays

• Git history is gone

• Your project is no longer a Git repository

So yes — no .git folder = no Git.

Why Does the .git Folder Exist?

Git needs a place to store:

• History of your code

• Information about branches

• Records of commits

• Tracking of changes

Instead of storing this randomly, Git keeps everything organized inside .git.

Think of .git as:

📦 A private database that stores the entire life story of your project

The Heart of Git: Git Objects

Inside the .git folder, Git stores data in the form of objects.

There are three main objects you should know:

1. Blob

2. Tree

3. Commit

Don’t worry about the names — focus on what they represent.

1️⃣ Blob – Stores File Content

A Blob represents the content of a file.

Important points:

• Blob does not store the file name

• Blob only stores the actual data

Example:

hello world

If two files (even with different names) have the same content,
👉 Git stores only one blob.

This is how Git saves space.

2️⃣ Tree – Stores Folder Structure

A Tree represents a directory (folder).

It stores:

• File names

• Folder names

• Links to blobs and other trees

So:

• Blob = file content

• Tree = folder structure

Together, blobs + trees describe how your project looks at a moment in time.

3️⃣ Commit – Takes a Snapshot

A Commit is like a snapshot of your project.

A commit contains:

• Reference to a tree (project structure)

• Author information

• Date & time

• Commit message

• Link to the previous commit

This linking is what creates Git history.

Think of a commit as:

📸 “This is how my project looked at this moment”

What Happens Internally When You Run git add?

When you run:

git add file.txt

Git does not create a commit yet.

Instead:

1. Git reads the content of file.txt

2. Creates a blob for that content

3. Stores it inside .git/objects

4. Adds it to a staging area

👉 The staging area is like a waiting room for changes.

So git add means:

“Git, please remember this version of the file”

What Happens Internally When You Run git commit?

When you run:

git commit -m "message"

Git:

1. Takes everything from the staging area

2. Builds a tree structure

3. Creates a commit object

4. Links it to the previous commit

Now the change becomes permanent history.

👉 If git add is preparing,
👉 git commit is saving forever.

How Git Tracks Changes (This is Important)

Here’s a key thing many beginners miss:

❌ Git does NOT store differences
✅ Git stores snapshots

Every commit is a full snapshot of the project — but Git is smart enough to reuse unchanged blobs.

This is why Git is:

• Fast

• Efficient

• Reliable

Build a Mental Model (Instead of Memorizing Commands)

Here’s the simplest mental model I use:

• .git = database

• Blob = file content

• Tree = folder structure

• Commit = snapshot + history

• git add = prepare snapshot

• git commit = save snapshot forever

Once this clicks, Git commands stop feeling scary.

You don’t need to remember everything inside .git.
You just need to understand why it exists and how Git thinks.