You type a few commands, things “work”, and you move on.
But the moment something breaks, Git suddenly feels scary.

The truth is: Git is not magic.
It’s just very systematic.

This blog is about what Git is doing behind the scenes, so you can understand it instead of memorizing commands.

First Things First: What Is the .git Folder?

When you run:

Git creates a hidden folder called: git init

This folder is Git itself.

Your project files are not Git.
Your code is not Git.
The .git folder is where Git stores everything it knows about your project.

If you delete the .git folder:

• Your code stays

• Git history is gone

• Commits disappear

• It’s no longer a Git repository

How Git Thinks About Your Project

Git does not track files like Google Drive or Dropbox.

Git tracks:

• content

• not filenames

• not folders

• not “versions” the way humans think

Git stores snapshots, not differences.

Each snapshot answers one question:

What did the project look like at this moment?

Git Objects: The Building Blocks

Inside the .git folder, Git stores everything as objects.

There are only three core ones you need to understand.

1. Blob — The File Content

A blob is just:

• the content of a file

• not the filename

• not the location

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

Think: Blob = This exact text exists

2. Tree — Folder Structure

A tree represents:

• folders

• file names

• how blobs are arranged

It connects:

• filenames → blobs

• directories → other trees

3. Commit — A Snapshot With Context

A commit points to:

• one tree (project structure)

• parent commit(s)

• author

• message

• timestamp

Simple Analogy

That’s it. No mystery.

What Actually Happens When You git add

This is where beginners get confused.

git add does NOT save your project.

Instead, Git:

1. Reads the file content

2. Converts it into blobs

3. Stores them inside .git/objects

4. Prepares a snapshot candidate

This area is called the staging area.

What Happens When You git commit

Now Git:

1. Takes everything from the staging area

2. Creates trees (structure)

3. Creates a commit object

4. Links it to the previous commit

5. Stores it permanently

How Git Tracks Changes (The Smart Part)

Git doesn’t say:

Line 3 changed from A to B

Instead, it says:

This snapshot exists.
This other snapshot also exists.

Differences are calculated later, not stored.

This makes Git:

• fast

• reliable

• powerful for branching

Why Hashes Matter (And Why Git Is Hard to Corrupt)

Every Git object has a hash (a long string like this):

a3f5c1e9...

This hash is created from:

• the content itself

If content changes → hash changes.

This gives Git two superpowers:

1. Integrity – corrupted data is detected

2. Deduplication – same content is stored once

“Git doesn’t trust names.
Git trusts math.”

Why This Mental Model Matters More Than Commands

If you only memorize commands:

• Git feels fragile

• Errors feel random

• You panic during conflicts

If you understand:

• blobs

• trees

• commits

• snapshots

Then Git becomes predictable.

You stop asking:

“What command should I run?”

And start thinking:

“What state do I want my project in?”

Final Thought

Git is not about commands.
Git is about states and history.

Once that clicks, everything else:

• branches

• merges

• rebases

becomes less scary.

You’re not fighting Git.
You’re just telling it what to remember.