Inside Git: How It Works and the Role of the .git Folder

A beginner-friendly guide to understanding Git internals (without memorizing commands)

When I first started using Git, I treated it like a magic box.
I typed git add and git commit, and somehow everything worked.
But one day I asked myself a simple question:

What is Git actually doing behind the scenes?

That curiosity led me to explore the .git folder—and honestly, that’s where Git really lives.
In this article, I’ll explain Git as a fresher, in simple language, focusing on how it works internally, not just commands.

Table of Contents

1. How Git Works Internally

2. What Is the .git Folder and Why It Exists

3. Understanding Git Objects: Blob, Tree, and Commit

4. What Happens During git add and git commit

5. How Git Tracks Changes Using Hashes

6. Building a Mental Model of Git

1. How Git Works Internally (High-Level View)

At its core, Git is a content-based version control system.

That means:

• Git does not track files by their names

• Git tracks snapshots of content

• Each snapshot is stored using a hash (SHA-1)

Internally, Git works like this:

Working Directory → Staging Area → Git Repository

You edit files in your project, stage them, and then commit them.
All the real data (history, objects, references) is stored inside the .git folder.

👉 Think of Git as a database of snapshots, not a tool that tracks line-by-line changes like traditional systems.

---

2. Understanding the .git Folder

What is the .git folder?

The .git folder is a hidden directory created when you run:

git init

This folder contains:

• Complete commit history

• All Git objects

• Branch information

• Configuration settings

If you delete .git, your project becomes a normal folder, not a Git repository.

---

Structure of the .git Directory

Common files and folders inside .git:

.git/
├── objects/
├── refs/
├── HEAD
├── index
├── config

Quick explanation:

• objects/ → Stores all Git data (blobs, trees, commits)

• refs/ → Stores branch and tag references

• HEAD → Points to the current branch

• index → Staging area (very important!)

• config → Repository-level configuration

---

3. Git Objects: Blob, Tree, and Commit

Git stores everything as objects.
There are three main objects you should understand.

• Reference 1 : Git Object Model

• Reference 2 : Entity Relationship Diagram

• Reference 3 : How Git Works Behind Closed Folders

1️⃣ Blob (File Content)

• Stores file content only

• No filename, no directory info

• Same content = same hash

📄 Example:
If two files have the same content, Git stores only one blob.

---

2️⃣ Tree (Folder Structure)

• Represents a directory

• Contains:

  • File names

  • Folder names

  • References to blobs or other trees

📁 Tree = Folder snapshot

---

3️⃣ Commit (Snapshot + Metadata)

A commit contains:

• Reference to a root tree

• Author information

• Commit message

• Parent commit(s)

📌 Commit = “This is how the project looked at this moment”

---

Relationship Summary

Commit → Tree → Blob

• Commit points to a tree

• Tree points to blobs (files)

• Blobs store actual content

---

4. What Happens During git add and git commit

This part helped me the most to understand Git.

• Reference 1 : Git Commands

• Reference 2 : Git staging area

• Reference 3: Git Workflow

---

🔹 What Happens During git add

git add file.txt

Internally:

1. Git reads the file content

2. Creates a blob object

3. Stores it in .git/objects

4. Updates the index (staging area)

👉 git add does not create a commit
👉 It prepares a snapshot for committing

---

🔹 What Happens During git commit

git commit -m "Initial commit"

Internally:

1. Git reads the staging area

2. Creates a tree object

3. Creates a commit object

4. Updates the branch reference

5. Moves HEAD to the new commit

👉 A commit is created only from staged data

---

5. How Git Uses Hashes to Track Changes

Git uses SHA-1 hashes (40-character strings) like:

e83c5163316f89bfbde7d9ab23ca2e25604af290

Why hashes are important:

• Ensure data integrity

• Same content → same hash

• Even a 1-character change → completely different hash

Git hashes are generated from:

• Object content

• Object type (blob, tree, commit)

That’s why Git is:

• Fast

• Reliable

• Very hard to corrupt

---

6. Building a Mental Model of Git (Not Commands)

Instead of memorizing commands, think like this:

• Git is a content-addressable database

• .git is where everything is stored

• Commits are snapshots, not diffs

• Branches are just pointers to commits

• git add updates the index

• git commit creates a new snapshot

Simple Mental Flow

Edit files
   ↓
Create blobs
   ↓
Stage (index)
   ↓
Create tree
   ↓
Create commit

---

Final Thoughts

As a fresher, understanding Git internals felt scary at first—but once I explored the .git folder, everything started making sense.

You don’t need to remember every command.
You just need to understand what Git is trying to do.

If you can visualize blobs, trees, commits, and the staging area—you’ve already won half the battle 🚀