Inside Git
How Git Works Internally
Most beginners learn Git like this:
git add
git commit
git push
They memorize commands.
But they don’t understand what’s actually happening.
Today, we’ll fix that.
Let’s look inside Git.
First Question: What Is the .git Folder?
When you run:
git init
Git creates a hidden folder called:
.git
This folder is the brain of your project.
Everything Git tracks is stored inside it.
Without .git,
there is no Git repository.
Why Does the .git Folder Exist?
Think of it like this:
Your project folder contains:
- Your code files
The .git folder contains:
History
Snapshots
Tracking information
Version relationships
It’s like a time machine storage room.
What’s Inside the .git Folder?
You don’t need to memorize all files inside.
But conceptually, it contains:
Objects (your data stored safely)
References (where commits point)
Configuration
Logs
The most important part is:
The objects.
Git Objects (The Core Idea)
Git stores everything as objects.
There are only three main types you need to understand:
Blob
Tree
Commit
That’s it.
Blob (File Content)
Blob = file data.
If you create:
index.html
Git does not store “index.html”.
It stores the content of the file as a blob.
Blob = just raw file content.
No filename.
No folder info.
Just data.
Tree (Folder Structure)
Tree = directory structure.
A tree connects:
Filenames
Folder names
Blobs
Think of it like a folder map.
Example:
project/
├── index.html
└── style.css
The tree object stores:
index.html → blob
style.css → blob
So:
Blob = file content
Tree = folder structure
Commit (Snapshot + Message)
Commit is the top level.
It contains:
A reference to a tree
Author info
Timestamp
Commit message
A pointer to previous commit
Commit = a snapshot of your project at one moment.
Relationship Diagram (Mental Model)
Commit
↓
Tree
↓
Blob (file content)
Commit → points to Tree
Tree → points to Blobs
That’s the structure.
What Happens During git add?
Let’s say you create:
app.js
When you run:
git add app.js
Git:
Takes the file content
Creates a blob object
Stores it inside
.git/objectsPrepares it in something called the staging area
Important:
Git does not save the filename first.
It saves the content as a blob.
What Happens During git commit?
When you run:
git commit -m "Add app.js"
Git:
Creates a tree object (project structure)
Creates a commit object
Links commit → tree
Links commit → previous commit
Stores everything inside
.git
Now you have a snapshot.
Not a diff.
Not just changes.
A full snapshot.
How Git Tracks Changes
Here’s the interesting part.
Git does NOT store files like:
v1
v2
v3
Instead:
It stores content using something called a hash.
What Is a Hash?
A hash is like a unique fingerprint.
When Git saves a blob, tree, or commit…
It generates a long ID like:
a3f5b8c9d4...
This ID is created from the content itself.
If the content changes even slightly…
The hash changes completely.
This ensures:
✔ Data integrity
✔ No corruption
✔ No accidental modification
Git knows if something was altered.
Why Hashes Are Powerful
If someone edits history manually…
The hash breaks.
If content changes…
The hash changes.
This makes Git very secure internally.
It trusts mathematics, not filenames.
Internal Flow (Simple View)
When You Save a File:
File → Blob → Stored in .git
When You Commit:
Blobs → Tree → Commit → Linked to previous commit
Everything is connected.
Like a chain.
Full Mental Model of Git
Think of Git as:
A database of snapshots.
Each snapshot:
Points to a tree
Tree points to blobs
Commit points to previous commit
Like this:
Commit3
↓
Commit2
↓
Commit1
A timeline you can travel.
Important Realization
Git does not think like:
“Version 1, Version 2, Version 3.”
It thinks like:
“Here is a chain of connected snapshots.”
That’s why it’s fast.
That’s why it’s reliable.
That’s why it scales for huge projects.
You Don’t Need to Memorize Everything
Just remember this structure:
Blob = file content
Tree = folder structure
Commit = snapshot
And all of it lives inside .git.
If you understand this mental model…
Git will never feel confusing again
