When I first learned Git, I used commands without really knowing what was happening.
Things worked—but Git felt confusing.

If you’ve ever wondered:

• What actually happens when I run git add?

• Where does Git store my code?

• How does Git remember every version?

This blog is for you.

We’ll look at how Git works internally, not in a complicated way, but in a way that makes Git feel logical.

First, Understand This One Thing 🧠

Git is not a file tracker.
Git is a content tracker.

It does not think in terms of files and folders.
It thinks in terms of content and snapshots.

And everything Git does happens inside one hidden folder:

📁 .git

Once this clicks, Git stops feeling magical.

The .git Folder: The Heart of Git ❤️

When you initialize a Git repository, Git creates a hidden folder called .git.

This folder contains:

• The entire history of your project

• All commits

• Branch information

• Internal data Git uses to work

Important thing to remember:

Your project files are outside .git,
but Git’s memory lives inside .git.

If this folder is removed, Git forgets everything.

What’s Inside the .git Folder

.git/ ├── objects/ ├── refs/ ├── HEAD ├── index └── config objects/ → where Git stores actual data

refs/ → keeps track of branches

HEAD → tells Git where you currently are

index → staging area data

config → project-level settings

Git doesn’t store history in your files. It stores history here.

Git Objects: How Git Stores Everything 🧱

Internally, Git stores data as objects.

Every object is saved using a hash, which is like a unique fingerprint.
If the content changes, the fingerprint changes.

There are three core Git objects you need to understand.

Nothing more. Nothing less.

Blob: Where File Content Lives 📄

A blob stores the actual content of a file.

That’s it.

Important things:

• It does not store the filename

• It stores only the content

• Same content = same blob

So if two files have identical content, Git stores it only once.

Git cares about what’s inside the file, not what the file is called.

Tree: How Git Understands Folders 📁

A tree represents a directory.

It stores:

• File names

• Links to blob objects

• Links to other trees (subfolders)

Think of a tree as a structure map.

It tells Git:

“This file name points to this content.”

Commit: A Snapshot in Time 📸

A commit is not just “saved code”.

A commit stores:

• A reference to a tree (project structure)

• Author information

• Commit message

• Link to the previous commit

A commit says:

“This is exactly how the project looked at this moment.”

Commits don’t store files directly.
They store references.

How These Objects Connect 🔗

This is the most important relationship in Git:

Commit
  |
  └── Tree
        ├── file → Blob
        ├── file → Blob
        └── folder → Tree

Simple way to remember:

• Blob = content

• Tree = structure

• Commit = snapshot + history

This is Git’s entire design.

How Git Tracks Changes (This Is the Key 🔑)

Git doesn’t compare files line by line.

Instead:

• Git calculates a hash of the content

• If content changes → new hash

• If content stays same → reuse old data

This is why Git is:

• Fast

• Reliable

• Memory efficient

Git tracks snapshots, not edits.

What Really Happens During git add

Many beginners think git add saves the code.
It doesn’t.

Internally, Git:

1. Reads file content

2. Creates a blob (if content is new)

3. Updates the index (staging area)

Conceptually:

Working Directory → Blob → Index

git add means:

“I want this version of the content to be included in the next snapshot.”

Nothing is permanent yet.

🧑‍💻What Really Happens During git commit

This is where history is created.

Internally, Git:

1. Reads what’s in the staging area

2. Builds tree objects

3. Creates a commit object

4. Moves the branch pointer forward

Conceptually:

Index → Tree → Commit → Branch

This is why:

If something is not staged, it cannot be committed.

Why Git Uses Hashes 🔐

Every Git object is identified by a hash.

This gives Git three superpowers:

• Data integrity (corruption is detectable)

• Exact version identification

• Safe collaboration

Even a tiny change creates a new hash.
That’s how Git knows something changed.

The Mental Model That Makes Git Easy 🧠

If you remember only this, Git will make sense:

• Git tracks content

• Everything lives inside .git

• Blobs store content

• Trees store structure

• Commits store snapshots

• Hashes connect everything safely

Commands are just a way to talk to this system.

Final Thoughts 🌱

Git is not hard by design.
It only feels hard when we use it without understanding it.

Once you understand how Git thinks internally, you stop guessing—and start using Git confidently.

This understanding will help you:

• Debug issues calmly

• Learn advanced Git faster

• Work professionally with teams