Inside Git: How It Works and the Role of the .git Folder
We all use Git daily. We memorize the commands: git add, git commit, git push. But for many developers, what happens after we hit enter is a black box. It feels like magic.
But Git isn’t magic—it’s a beautifully simple database consisting of a few fundamental concepts.
In this article, we are going to stop memorizing commands and start building a mental model of how Git actually works. We’ll look inside the hidden .git folder, break down the core objects, and trace exactly what happens when you save your code.
1. The .git Folder: The Brain of the Operation
If you initialize a repository (git init) and look at your project folder, you see your code. But if you enable "show hidden files," you’ll see a directory called .git.
This folder is your repository.
Everything else in your project folder is just the "Working Directory"—a temporary checkout of one version of your files. If you delete your working files, you can get them back. If you delete the .git folder, your project history is gone forever.
Diagram: Structure of the .git Directory
Here is what that folder looks like on the inside. It’s not a mess; it’s a structured database.
Why it exists: The .git folder is a content-addressable filesystem. It stores compressed snapshots of your files and a history of how they relate to one another.
2. Git Objects: Blobs, Trees, and Commits
Git is fundamentally a key-value store. You give it data, and it gives you back a unique key (a hash). To understand Git, you only need to understand three types of objects stored in that objects/ folder
A. The Blob (Binary Large Object)
When you store a file in Git, it doesn't care about the filename. It only cares about the content.
Git compresses the file content.
It ignores the filename.
Think of it as: The raw data of a file.
B. The Tree
If a Blob is the file content, the Tree is the directory.
A Tree maps names (filenames) to Blobs (contents).
It can also contain other Trees (subdirectories).
Think of it as: The folder structure.
C. The Commit
This is the object we are most familiar with. A commit is a wrapper that gives context to a Tree.
It points to a specific Tree (the snapshot of the project at that moment).
It contains metadata (Author, Message, Date).
It points to a Parent Commit (the commit that came before it).
Diagram: Relationship between Commits, Trees, and Blobs
This visualization shows how these objects link together to form a snapshot of your project.
3. How Git Tracks Changes (The Power of Hashes)
You might have noticed the weird strings of numbers and letters in Git (e.g., 8a7b3c...). These are SHA-1 Hashes.
Git ensures integrity by hashing everything.
Git takes the content of a file.
It runs it through a hashing algorithm.
It gets a unique 40-character string.
If you change one single character in a file, the hash changes completely. Because the Blob hash changes, the Tree hash pointing to it must change. Because the Tree hash changes, the Commit hash pointing to it must change.
This is why you can't alter history in Git without breaking the chain—it’s a chain of mathematical certainty.
4. The Internal Flow: git add vs git commit
Let's trace the lifecycle of a change to see how the .git folder updates in real-time.
Step 1: git add .
When you run this command, you aren't just selecting files. You are actively updating the database.
Git takes the content of your modified files.
It creates Blob objects for them in the .git/objects folder.
It updates the Index (the Staging Area) to point to these new blobs.
Step 2: git commit -m "Update"
When you run this, you are finalizing the snapshot.
Git creates a Tree object from your current Index.
Git creates a Commit object pointing to that Tree.
Git updates your current branch (e.g., refs/heads/main) to point to this new Commit.
Diagram: Internal Flow of Add and Commit
Thanks for reading blogs …. share your valuable feedback with us
