Most developers use Git every day, but very few understand what Git is actually doing behind the scenes. This blog is not about memorizing commands — it’s about understanding Git.
If you can picture how Git works internally, everything else (commands, errors, conflicts) becomes much easier.
How Git Works (Big Picture)
At its core, Git is a smart storage system.
Instead of thinking:
“Git tracks my files”
Think this way:
Git stores snapshots of your project and connects them together.
Each snapshot is saved permanently and identified using a unique hash. All this data lives inside one folder:
👉 the .git folder
What Is the .git Folder and Why Does It Exist?
The .git folder is the brain of Git.
- It is created when you run
git init - It stores your entire project history
- It remembers every commit, branch, and change
If you delete the .git folder:
Your project becomes a normal folder — Git forgets everything.
So even though you work with visible files, Git only cares about what’s inside .git.
Structure of the .git Directory (Simple View)
.git/
├── objects/ → All saved data (snapshots)
├── refs/ → Branch pointers
├── HEAD → Where you are right now
├── index → Staging area
├── config → Repo settings
└── logs/ → Movement history
You don’t need to memorize this. Just remember:
- objects store data
- index is staging
- HEAD tells Git your current position
Git Objects: The Core Building Blocks
Git stores everything as objects. There are only three you really need to understand.
1. Blob — File Content
A blob stores the actual content of a file.
Important details:
- No file name
- No folder info
- Same content = same blob
Think of a blob as:
“Pure file data, nothing else.”
2. Tree — Folder Structure
A tree represents a directory.
It stores:
- File names
- Folder names
- Links to blobs and other trees
Think of a tree as:
“How everything is arranged.”
3. Commit — Project Snapshot
A commit is a snapshot of your project at a moment in time.
A commit stores:
- A reference to a tree
- Parent commit(s)
- Message and author info
Think of a commit as:
“This exact version of the project.”
How Commits, Trees, and Blobs Are Connected
Commit
↓
Tree
↓
Blobs
Example:
Commit
└── Tree
├── index.html → Blob
└── app.js → Blob
This design is why Git is fast and efficient.
How Git Tracks Changes (Key Idea)
Git does not store line-by-line differences like older systems.
Instead:
Git stores full snapshots, but reuses unchanged parts.
If a file doesn’t change:
- Git reuses the same blob
- No extra space is wasted
That’s how Git stays fast even with thousands of commits.
What Happens Internally During git add
When you run:
git add file.txt
Git does this internally:
- Reads the file content
- Converts it into a blob
- Stores the blob in
.git/objects - Updates the index (staging area)
Flow:
Working Directory
↓ git add
Staging Area (index)
↓
Blob stored in .git/objects
At this point:
- The file is staged
- No commit exists yet
What Happens Internally During git commit
When you run:
git commit -m "message"
Git performs these steps:
- Creates a tree from staged files
- Creates a commit object
- Links it to the previous commit
- Moves HEAD forward
Flow:
Staging Area
↓ git commit
Tree created
↓
Commit created
↓
HEAD updated
How Git Uses Hashes (Why Git Is Trustworthy)
Every Git object is named using a hash.
This gives Git superpowers:
- Same content → same hash
- Small change → completely new hash
- Corruption is easy to detect
In simple words:
Git knows if anything has been altered or damaged.
This is why Git history is reliable.
The Mental Model to Remember
Don’t memorize commands. Remember this instead:
- Git stores objects
- Objects are connected by references
- Commits are snapshots, not diffs
- HEAD tells Git where you are
Once this clicks, Git feels logical instead of confusing.
Final Thoughts
Understanding Git internally makes you a stronger developer.
You’ll:
- Debug issues faster
- Handle merges confidently
- Explain Git clearly in interviews
Most importantly, Git will finally make sense.
Happy learning 🚀
Top comments (0)