Inside Git

Most of us beginner Developer think git it just give these command

git add → git commit → git push → pray nothing breaks

But Git becomes really easy once you understand one thing:

Git is not a set of commands. Git is a database.

And that database lives inside a hidden folder: .git/

Everything — your commits, branches, history, rollback ability — lives there.

If you delete .git, your code still exists… but Git forgets your project

Let’s open the black box and understand what actually .git/ folder has inside.

1. Git’s Real Model (The 3 Areas)

Git is NOT tracking files directly , but it tracks snapshots moving through 3 layers:

Think of Git Like Google Docs

You first choose changes (git add),then permanently record them (git commit). git dont not auto save the file changes it is manual done with the git command

2. The Folder — Structure of Git

Run: ls -a

You’ll see: .git/ hidden folder

What each part means

Important idea:

Git is mostly just reading and writing files inside .git

When you run a command, Git is literally editing text pointers and compressed files.

3. Git Doesn’t Store Files — It Stores Objects

Git stores only 3 types of objects

Blob   → File content
Tree   → Folder structure
Commit → Snapshot in time

Blob (file data)

Blob = content i.e only data

Example: hello.txt → "Hello World"

Git stores: Blob: "Hello World"

If you rename the file → same blob
If two files have same content → same blob

Git deduplicates automatically

Tree (folder structure)

Tree connects names to blobs

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

Tree stores:

index.html → blob A
style.css  → blob B

So : Blob = WHAT ,Tree = WHERE

Commit (snapshot)

Commit points to a tree and adds metadata:

Author
Time
Message
Parent commit

So commit is basically: "At this time, project looked like THIS"

Relationship Between Them

Commit
  ↓
Tree (root folder)
  ↓
Files (blobs)

4. What Actually Happens During git add

When you run:

git add index.html

Git does NOT commit.

It does this:

1. Reads file content

2. Calculates hash

3. Stores content in .git/objects

4. Updates staging index

So now:

Working directory  → modified
Index              → saved snapshot
Repo               → unchanged

Important: You can edit the file again after staging — Git still remembers the staged version.

That’s why Git shows:

Changes staged
Changes not staged

Because they are literally two different snapshots.

5. What Happens During git commit

Now you run:

git commit -m "Add homepage"

Git performs:

1. Create tree from staged files

2. Create commit pointing to tree

3. Move branch pointer to new commit

That’s it.

Git never edits old commits.

It only creates new ones.

So history is immutable.

6. Why Git Uses Hashes Very Important

Every object has a fingerprint: SHA Hash

Example:

blob → e4f1c3... commit → a91bc2...

This changes if even ONE character changes.

So Git guarantees:

1) Data Integrity

If file changes → hash changes → detected

2) No duplicates

Same content = same hash

3) Tamper proof history

Changing old commit breaks entire chain

That’s why Git is trustworthy.

7. How Git Tracks Changes

Git DOES NOT store differences.

Git stores full snapshots.

But it reuses unchanged files via hashes.

So it looks like diff-based versioning but is actually snapshot-based.

This is the key mental shift: Git is a snapshot tracker, not a file editor history.

The Full Internal Flow

Edit file
   ↓
git add
   ↓
Blob stored
Index updated
   ↓
git commit
   ↓
Tree created
Commit created
Branch moved

Thank You

If this helped you finally understand Git instead of memorizing it —