Skip to main content

Command Palette

Search for a command to run...

Inside Git

Published
4 min readView as Markdown

How Git Works Internally

Most beginners learn Git like this:

git add
git commit
git push

They memorize commands.

But they don’t understand what’s actually happening.

Today, we’ll fix that.

Let’s look inside Git.

First Question: What Is the .git Folder?

When you run:

git init

Git creates a hidden folder called:

.git

This folder is the brain of your project.

Everything Git tracks is stored inside it.

Without .git,
there is no Git repository.

Why Does the .git Folder Exist?

Think of it like this:

Your project folder contains:

  • Your code files

The .git folder contains:

  • History

  • Snapshots

  • Tracking information

  • Version relationships

It’s like a time machine storage room.

What’s Inside the .git Folder?

You don’t need to memorize all files inside.

But conceptually, it contains:

  • Objects (your data stored safely)

  • References (where commits point)

  • Configuration

  • Logs

The most important part is:

The objects.

Git Objects (The Core Idea)

Git stores everything as objects.

There are only three main types you need to understand:

  1. Blob

  2. Tree

  3. Commit

That’s it.

Blob (File Content)

Blob = file data.

If you create:

index.html

Git does not store “index.html”.

It stores the content of the file as a blob.

Blob = just raw file content.

No filename.
No folder info.
Just data.

Tree (Folder Structure)

Tree = directory structure.

A tree connects:

  • Filenames

  • Folder names

  • Blobs

Think of it like a folder map.

Example:

project/
 ├── index.html
 └── style.css

The tree object stores:

  • index.html → blob

  • style.css → blob

So:

Blob = file content
Tree = folder structure

Commit (Snapshot + Message)

Commit is the top level.

It contains:

  • A reference to a tree

  • Author info

  • Timestamp

  • Commit message

  • A pointer to previous commit

Commit = a snapshot of your project at one moment.

Relationship Diagram (Mental Model)

Commit

Tree

Blob (file content)

Commit → points to Tree
Tree → points to Blobs

That’s the structure.

What Happens During git add?

Let’s say you create:

app.js

When you run:

git add app.js

Git:

  1. Takes the file content

  2. Creates a blob object

  3. Stores it inside .git/objects

  4. Prepares it in something called the staging area

Important:

Git does not save the filename first.

It saves the content as a blob.

What Happens During git commit?

When you run:

git commit -m "Add app.js"

Git:

  1. Creates a tree object (project structure)

  2. Creates a commit object

  3. Links commit → tree

  4. Links commit → previous commit

  5. Stores everything inside .git

Now you have a snapshot.

Not a diff.
Not just changes.

A full snapshot.

How Git Tracks Changes

Here’s the interesting part.

Git does NOT store files like:

v1
v2
v3

Instead:

It stores content using something called a hash.

What Is a Hash?

A hash is like a unique fingerprint.

When Git saves a blob, tree, or commit…

It generates a long ID like:

a3f5b8c9d4...

This ID is created from the content itself.

If the content changes even slightly…

The hash changes completely.

This ensures:

✔ Data integrity
✔ No corruption
✔ No accidental modification

Git knows if something was altered.

Why Hashes Are Powerful

If someone edits history manually…

The hash breaks.

If content changes…

The hash changes.

This makes Git very secure internally.

It trusts mathematics, not filenames.

Internal Flow (Simple View)

When You Save a File:

File → Blob → Stored in .git

When You Commit:

Blobs → Tree → Commit → Linked to previous commit

Everything is connected.

Like a chain.

Full Mental Model of Git

Think of Git as:

A database of snapshots.

Each snapshot:

  • Points to a tree

  • Tree points to blobs

  • Commit points to previous commit

Like this:

Commit3
  ↓
Commit2
  ↓
Commit1

A timeline you can travel.

Important Realization

Git does not think like:

“Version 1, Version 2, Version 3.”

It thinks like:

“Here is a chain of connected snapshots.”

That’s why it’s fast.
That’s why it’s reliable.
That’s why it scales for huge projects.

You Don’t Need to Memorize Everything

Just remember this structure:

Blob = file content
Tree = folder structure
Commit = snapshot

And all of it lives inside .git.

If you understand this mental model…

Git will never feel confusing again