Unlocking Git's Secrets: Demystifying the Inner Workings of the .git Folder
Opening the "Black Box": What actually happens inside the .git folder?
Hey guys, back again!
So, in my last few posts, I talked about how to use Git (you know, the usual add, commit, push dance). But honestly? I felt like I was just memorising magic spells without knowing how the magic actually worked. It felt like if I made one wrong move, the whole thing would explode.
So, I decided to peek under the hood and look into the .git folder. It’s actually kind of mind-blowing how simple (and also weird) it is. Here is my attempt to explain the "internals" of Git without sounding like a textbook.
1. That Mysterious .git Folder
If you go to your project folder and show hidden files, you’ll see a folder named .git.
Do not delete this. I learned the hard way that if you delete this folder, your project is no longer a "Git repo." It just becomes a regular folder, and your entire history—every save point you ever made—is gone forever.
Think of the .git folder as the brain of your project. It stores every version of every file you’ve ever committed. If your project files are the "body," the .git folder is the "memory."
2. The Big Three: Blobs, Trees, and Commits
Git doesn't see "files" and "folders" the way we do. It sees Objects. Everything in Git is stored as an object with a weird name like e69de29bb2d1d643....
This name is a Hash (specifically SHA-1). It’s basically a unique fingerprint. If you change even one comma in your code, the fingerprint changes completely. This is how Git knows for sure that nothing has been corrupted or lost.
There are three main types of objects you need to know:
Blobs (Binary Large Objects): This is just a fancy word for your file content. Git doesn't care about the filename here; it only cares about what’s inside the file. If you have two different files with the exact same text, Git only stores one blob! Efficiency, right?
Trees: Think of these as Folders. A Tree object lists the blobs (files) and other trees (sub-folders) inside it. It links the filenames to the blobs.
Commits: This is the "snapshot." A commit object points to a specific Tree (representing the project state) and contains the author, the date, and the parent commit (the one that came before it).
3. What happens when you git add and git commit?
This was the "Aha!" moment for me. Here’s the internal flow:
Step 1: git add
When you run git add, Git takes the content of your file and creates a Blob. It then puts that blob into the .git/objects folder. It also updates a file called the Index (or Staging Area), which is basically a list saying, "Hey, next time we commit, include this blob."
Step 2: git commit
This is where the magic happens. Git:
Creates a Tree object to represent the structure of your project right now.
Creates a Commit object that points to that Tree.
Moves the HEAD (the "You Are Here" pointer) to this new commit.
4. Why does this matter?
Before I looked into this, I thought Git was saving "diffs"—like, it just saved the lines I changed. But that’s not true! Git actually takes a full snapshot of your files every time. If a file hasn't changed, it just points to the old blob from the previous version to save space.
The Mental Model:
Instead of thinking of Git as a list of changes, think of it as a Map of Snapshots. Because every commit has a unique hash based on its content, it's basically impossible to lose data or have a "silent error."
It’s like Lego. Every commit is a finished structure. If you want to change it, you don't just swap a brick; you build a new version of the structure using some of the old pieces and some new ones, then take a photo of it.
Summary for my fellow students:
The .git folder is the database.
Hashes are the fingerprints that keep everything safe.
Blobs = Content, Trees = Folders, Commits = Snapshots.
Honestly, knowing this makes the error messages in Git make way more sense. You stop seeing it as a buggy tool and start seeing it as a very organised, very fast librarian.