How Git Works and the Role of the .git Folder

We all know the commands: git add, git commit, git push. But have you ever wondered how Git actually keeps track of everything?

For many developers, Git is a "black box"—magic happens inside, and version history comes out. But if you peek inside, you’ll realize that Git isn't magic at all. It is a deceptively simple database.

Today, we are going to open the hood and look at the engine: the .git folder.

The .git Folder: The Brain of the Operation

When you run git init in a folder, Git creates a hidden directory called .git.

This folder isn't just a settings file; it is your repository.

If you have a project with 10 years of history and you delete your source code files, you can get them back. But if you delete the .git folder, your project history, branches, and commits are gone forever. It contains:

• refs: Pointers to where your branches (like main) are currently pointing.

• objects: The database where all your files and commits are stored.

• HEAD: A text file that tells Git which branch you are currently on.

The Git Object Model: Building a Mental Map

To understand how Git tracks changes, you need to understand the Object Model. Git treats your data as a set of snapshots, not a stream of changes.

Everything in Git is stored as one of three main objects. Think of them as Lego blocks.

1. The Blob (Binary Large Object)

A Blob stores the content of a file, but not its name. If you have a file readme.txt containing the text "Hello World," Git compresses "Hello World" and stores it as a Blob.

• Analogy: A polaroid photo of a page of text.

2. The Tree

A Tree solves the problem of filenames. It stores the directory structure. A Tree maps names to Blobs (or other Trees). It says: "The file readme.txt corresponds to this specific Blob."

• Analogy: A folder on your computer that holds files and other folders.

3. The Commit

The Commit is the wrapper. It doesn't hold file data itself. Instead, it holds:

• Who made the save (Author).

• When they made it (Date).

• A message ("Fixed bug").

• A pointer to a Tree (the snapshot of the project at that moment).

• A pointer to the Parent Commit (the commit that came before it).

How Git Tracks Changes (The add and commit Cycle)

Let's slow down the standard workflow to see what happens internally.

When you run git add .

Most people think git add it just puts files in a waiting room. It actually does something more permanent:

1. Git takes the content of your modified files.

2. It compresses them into Blobs.

3. It stores those Blobs immediately into the .git/objects folder.

This is why you can sometimes recover files you "added" but never "committed." The data is already in the database!

When you run git commit

Now that the Blobs exist, git commit does the paperwork:

1. It creates a Tree object that lists all the files and their matching Blobs.

2. It creates a Commit object that points to that Tree.

3. It updates the current branch (like main) to point to this new Commit.

The Secret Sauce: Hashes

You’ve seen those long, ugly strings of numbers and letters (a1b2c3d...). These are SHA-1 Hashes.

Git doesn't assign ID numbers like 1, 2, or 3. Instead, it takes the contents of a file and calculates a unique hash (fingerprint) for it.

• Integrity: If you change a single comma in a file, the hash changes completely.

• Deduplication: If you have two files with the same text, Git only stores one Blob. It's smart enough to know they are identical, saving massive amounts of space

Conclusion: It’s Just a Graph

Once you understand this, Git becomes less scary. It’s just a graph of Commits pointing to Trees, which point to Blobs.

When you move between branches, Git simply looks at the graph, finds the Tree for that branch, and unpacks the Blobs back into files on your computer.

Understanding the .git folder transforms you from a user who creates commands into a developer who understands the tool.