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

You already type git add, git commit, and git push. They do the job. But do you know what actually happens when you press Enter? This article opens the black box and shows what Git stores inside the hidden .git folder.

Start a repo

mkdir my-app
cd my-app
git init

git init creates the .git folder. That folder is the repository keep it safe. Delete it and your project forgets its history.

Think of Git like a parcel system

Imagine you’re sending parcels by train across India. Each parcel has a unique receipt number. If two parcels contain the same book, the railway uses the same packaging and receipt to save space. Git works similarly:

• Files are parcels (content).
• Receipts (hashes) identify parcels by content, not by name.
• The depot (.git) stores parcels and receipts, and keeps track of which receipts belong to which shipment (commit).

This idea storing content by its fingerprint is the heart of Git.

What is inside .git (the control room)
You don’t usually open .git, but it contains everything Git needs:

• objects/ — where all actual data lives (file contents, folders, commits).
• refs/ — pointers to commits (branches, tags).
• HEAD — which branch you’re on right now.
• index — the staging area (what will go into the next commit).
• config, hooks/, info/ — settings and helper scripts. Think: .git is not a spare folder. It is the repository. The rest of your project is just the working copy.

The three building blocks
Git stores everything using only three object types:

• Blob- the raw file content. No name, no path. Just bytes. Analogy: the book inside the parcel.
• Tree- a directory listing that maps names → blobs or subtrees. Analogy: the list of parcel labels inside a crate.
• Commit- a snapshot of the whole project at one moment. It points to a top-level tree and to previous commit(s). It includes author, date, and message. Analogy: a train manifest that points to the crate (tree) and previous manifests.

All these objects live under objects/ and are named by a hash (their fingerprint).

What git add actually does

You may say “I staged the file.” Internally:

• Git reads the file content from your working folder.
• It creates a blob object from that content (unless an identical blob already exists).
• It stores the blob under .git/objects/ using a name derived from a hash.
• It updates the index with a mapping: filename → blob-hash.

So staging is preparing a list of exact content objects to include in the next snapshot.

What git commit actually does

When you commit:

• Git reads the index (the staged blueprint).
• It creates tree objects that represent directory structure and map filenames to blob hashes.
• It creates a commit object that points to the top tree and to parent commits; commit stores message, author, time.
• It updates a branch ref (like refs/heads/main) to point to the new commit and leaves HEAD pointing there.

Result: a new snapshot is saved. Git only writes new objects for changed content unchanged blobs are reused.