This chapter is not about learning new Git commands.
It’s about answering the question every curious developer eventually asks:
“What is Git actually doing behind the scenes?”
This is the story of Kartikey going one level deeper inside Git itself.
“This is where Kartikey’s journey begins.”
The Hidden Door
Kartikey has been using Git for a while now.
He can commit.
He can create branches.
He feels comfortable.
Then one day, while exploring his project folder, he notices something unusual.
A hidden directory.
.git
Kartikey pauses.
“What is this folder… and why does it exist?”
Git doesn’t answer immediately.
The .git Folder Revealed
Finally, Git speaks.
“Everything you trust me for lives here.”
Kartikey opens the .git folder.
It’s not code.
It’s not configuration alone.
It’s Git’s entire memory.
Git explains:
This folder stores history.
This folder stores snapshots.
This folder stores relationships.
This folder stores integrity.
Then Git adds quietly:
“Delete this folder and I forget everything.”
Kartikey understands.
The .git folder isn’t optional.
It is Git.
Git Doesn’t Track Files
Kartikey assumes Git tracks files line by line.
Git corrects him.
“I don’t track files.”
“I track content.”
Whenever Kartikey writes code, Git doesn’t care about:
Git only cares about:
What the content is?
Whether it has changed?
That’s when Git introduces its core building blocks.
The Three Objects of Git
Git draws three symbols in the air:
“Everything I store is one of these.”
Blob - The Content
A blob is just raw content.
No filename
No folder
Just data
If two files have the same content, Git stores only one blob.
Git says calmly:
“I don’t duplicate memory” .
Tree - The Structure
A tree represents:
Folder structure
File names
How blobs are arranged.
Think of a tree as a map, not the content itself.
Commit - The Snapshot
A commit ties everything together.
It points to:
Git explains:
“A commit is not a change.”
“It’s a snapshot.”
Kartikey starts seeing Git differently.
What Really Happens During “git add”?
Kartikey types:
git add index.js
Nothing seems to change.
But inside Git, everything changes.
Git explains:
Git reads the file content.
Git creates a blob.
Git calculates a hash.
Git stores it inside .git/objects.
Git updates the index (staging area).
Git adds:
“The staging area is a list of hashes, I’m preparing to remember.”
Kartikey realizes something important:
git add doesn’t save history, It prepares reality.
What Really Happens During “git commit”?
Now Kartikey commits:
git commit -m "Save progress of index.js file."
Git goes to work.
Internally:
Git creates a tree from staged blobs.
Git creates a commit object.
Git links it to the previous commit.
Git moves HEAD forward.
Git says:
“This is when time moves forward.”
Kartikey understands:
Commits don’t store differences.
They store complete snapshots, efficiently.
The Power of Hashes
Kartikey notices strange strings everywhere.
Long.
Random.
Unreadable.
Git explains:
“Those are hashes.”
Every blob, tree, and commit is identified by a cryptographic hash (SHA-1 or SHA-256).
This means:
Change the content → the hash changes.
Corrupt the data → the hash does not match.
History cannot be secretly altered.
Git says calmly:
“My memory is tamper-proof.”
Kartikey finally understands why Git feels so reliable.
The Mental Model Clicks
Git summarizes:
Files → Blobs
Folders → Trees
Snapshots → Commits
Hashes → Identity
.git folder → Memory
Git tells Kartikey:
“Don’t memorize commands.”
“Understand how I think.”
That’s when it clicks.
Seeing Git Clearly
Kartikey looks at Git differently now.
Not as magic.
Not as commands.
But as a content-addressed memory system.
He smiles.
Because now:
Git feels predictable.
Git feels safe.
Git feels logical.
And once again, Kartikey realizes:
“Git doesn’t just help him write code.”
“It helps him trust his progress.”
If Git has ever felt mysterious, you’re not alone.
Understanding Git internally doesn’t make you a power user, it makes you a calm developer.
And this is only the beginning of Kartikey’s journey.