Let’s build a strong mental model step-by-step.

🧠 Big Picture: What Git Really Is

👉 Git is a content tracker, not a file tracker.

Most people think:

“Git tracks files.”

But internally:

Git tracks snapshots of content using hashes.

Every time you commit, Git stores a snapshot of your project — not just the changes.

📁 Understanding the .git Folder

When you run:

git init

Git creates a hidden folder:

.git/

This folder is the entire Git repository database.

If you delete .git → your Git history is gone.

📦 What’s Inside .git?

Typical structure:

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

Let’s understand these conceptually.

1️⃣ objects/ → The Database

This is where Git stores everything:

• File contents

• Directory structures

• Commits

All stored as compressed objects.

👉 This is Git’s heart.

2️⃣ refs/ → Branches

Stores pointers to commits.

Example:

refs/heads/main

This contains a commit hash.

Branches are just:

A pointer to a commit.

Nothing more.

3️⃣ HEAD

HEAD tells Git:

“Which branch am I currently on?”

Example:

ref: refs/heads/main

4️⃣ index → Staging Area

This is the staging area.

When you run:

git add file.txt

Git updates this index file.

🧱 Git Objects (Core Concept)

Git stores everything as objects.

There are only 3 main types:

1️⃣ Blob (Binary Large Object)

Blob = file content only

It does NOT store:

• File name

• Folder path

Only raw content.

Example:

File:

hello.txt
Hello World

Git creates a blob for:

Hello World

2️⃣ Tree

Tree = folder structure

It connects:

• File names

• Blob hashes

• Subdirectories

Think of it like:

project/
 ├── hello.txt
 └── app.js

Tree stores:

• "hello.txt" → blob hash

• "app.js" → blob hash

3️⃣ Commit

Commit stores:

• Tree hash (snapshot)

• Parent commit hash

• Author

• Date

• Message

Think of commit like:

Commit:
  points to → Tree
  parent → previous commit

This creates a chain.

🔐 How Git Uses Hashes

Git uses SHA-1 hash (40 character string).

Example:

e99a18c428cb38d5f260853678922e03abd8334

The hash is generated from:

content + metadata

If you change even 1 character → completely new hash.

Why Hashes Matter

1. Unique identity

2. Detects tampering

3. Ensures integrity

4. Makes Git fast

If content changes → hash changes → Git knows it's different.

⚙️ What Happens During git add (Internally)

Suppose you create:

hello.txt

Step 1: You run

git add hello.txt

Internally Git:

1. Reads file content

2. Creates a blob object

3. Generates SHA-1 hash

4. Stores blob in:

    .git/objects/
   

5. Updates the index (staging area)

Important:

No commit yet. Just staged snapshot.

⚙️ What Happens During git commit

When you run:

git commit -m "First commit"

Internally:

1. Git reads index

2. Creates a tree object (directory snapshot)

3. Creates commit object

   • Points to tree

   • Points to parent commit

4. Updates branch pointer

5. HEAD now points to new commit

Now snapshot is permanent.

🔁 How Git Tracks Changes

Important concept:

Git does NOT store:

“Difference between versions”

Git stores:

“Full snapshots”

But it’s smart.

If file hasn't changed:

• It reuses old blob

• Doesn’t duplicate storage

So internally:

Commit 1 → blob A
Commit 2 → blob A (same)

No duplication.

🧠 Mental Model of Git (Very Important)

Think of Git like:

📸 A Camera System

• git add → Put files in photo frame

• git commit → Take a photo

• Branch → Label pointing to a photo

• HEAD → Current camera position

Each commit:
📸 Snapshot of whole project

🔗 How Everything Connects

HEAD
  ↓
Branch (main)
  ↓
Commit
  ↓
Tree
  ↓
Blobs

That’s the internal chain.

🚀 Why Git Is Powerful

Because:

1. Everything is content-based

2. Everything is immutable

3. Everything is linked by hashes

4. Branches are lightweight pointers

Branch creation:

Just create new pointer to commit.

That’s why branching is fast.

💡 Advanced Insight (But Simple)

Git is basically:

A key-value database

Where:

Key   = SHA-1 hash
Value = Object content

That’s it.

🏗 Final Mental Model Summary

Git is:

• A content-addressable storage system

• That stores snapshots

• Connected by hashes

• With lightweight branch pointers

🔥 If You Remember Only 5 Things

1. Git stores snapshots, not diffs.

2. Everything is stored in .git.

3. Blob = file content.

4. Tree = folder structure.

5. Commit = snapshot + metadata.

Diagram for the understanding:-

Today we use Git and think it’s normal.

But imagine this:

👉 No Git
👉 No GitHub
👉 No cloud
👉 Just folders and pendrives

That’s how development worked earlier.

And it was a mess.

💾 The Pendrive Analogy in Software Development

Let’s imagine 3 developers working on a project:

• Irfan

• Aamir

• Rahul

They are building a website.

There is no Git.

What do they do?

🧍 Step 1: Single Developer Situation

You create a project folder:

project/

You make changes.

Before trying something risky, you copy the folder:

project_final
project_final2
project_latest
project_latest_final
project_latest_final_REAL

Sound familiar? 😅

This is manual version control.

❌ Problem 1: Folder Chaos

After 2 weeks, your desktop looks like:

project
project_new
project_new2
project_final
project_final_v2
project_final_v2_updated
project_latest_final_working

Now question:

👉 Which one is correct?
👉 Which one is deployed?
👉 Which one has latest bug fix?

You don’t know.

👥 Step 2: Multiple Developers (Pendrive Era)

Now imagine team collaboration.

Irfan works on his laptop.
He copies project into pendrive.
Gives it to Aamir.

Aamir:

• Makes changes

• Overwrites some files

• Adds new features

Then gives pendrive to Rahul.

Meanwhile…

Irfan also made changes on his laptop.

Now we have:

• Irfan’s version

• Aamir’s version

• Rahul’s version

All different.

❌ Major Problems Before Version Control

Let’s break them down clearly.

1️⃣ Overwriting Code

Example:

Irfan edits:

login.js

At the same time, Aamir edits:

login.js

Now someone copies file over pendrive.

💥 One person's work is gone.

No warning.
No merge.
No history.

Just overwritten.

2️⃣ Losing Changes

You delete something accidentally.

Or your system crashes.

Or you forgot to copy the correct folder.

💀 Changes lost forever.

No recovery.

3️⃣ No History

You find a bug.

You ask:

“Who changed this file?”

No answer.

“When was this added?”

No answer.

“What was the previous version?”

No answer.

Everything is manual.

4️⃣ No Collaboration Tracking

In team:

• Who added this feature?

• Who broke the code?

• Why was this line removed?

There was no record.

Just guessing.

5️⃣ Email Version Control (Even Worse)

Developers started emailing ZIP files:

project_v1.zip
project_v2_new.zip
project_final.zip
project_final_revised.zip
project_final_final.zip

Inbox becomes nightmare.

Now imagine 10 developers doing this.

Chaos.

🧠 Real-World Team Problem Example

Let’s say company has:

• Backend team

• Frontend team

• QA team

Without version control:

Backend changes API.
Frontend doesn’t know.
App breaks.

QA tests wrong version.

No synchronization.

No central truth.

📦 Why This Didn’t Scale

Small projects → manageable.

But large systems like:

• Windows

• Linux

• Facebook

• Banking systems

With 100+ developers?

Impossible without version control.

🔄 The Core Problem

Before version control:

Everything was:

• Manual

• Unstructured

• Risky

• Untraceable

Developers needed:

✔ History
✔ Backup
✔ Collaboration
✔ Accountability
✔ Safe experimentation

💡 So What Was the Solution?

Version Control Systems (VCS).

Instead of copying folders manually:

We let a system:

• Track every change

• Record who made it

• Store history

• Allow collaboration safely

• Recover old versions

🧠 Mental Shift

Old mindset:

“Save new folder every time.”

New mindset:

“Let system track changes automatically.”

🌍 Why Version Control Became Mandatory

Because modern development requires:

1️⃣ Multiple Developers

People work simultaneously.

2️⃣ Continuous Updates

Software never stops evolving.

3️⃣ Safe Experimentation

Developers need branches.

4️⃣ Accountability

Every change must be traceable.

5️⃣ Backup & Recovery

Nothing should be permanently lost.

🔗 Connecting Back to Git

Git solves pendrive problems by:

🧭 The Big Realization

Version control is not just a tool.

It is:

A time machine for your code.

You can:

• Go back in time

• See who changed what

• Undo mistakes

• Create parallel universes (branches)

• Merge realities

Diagram for the understanding:-

• Git is a Distributed Version Control System (DVCS) used to track changes in files and source code during software development.

• Git is a distributed version control system that manages and tracks project changes efficiently.

Why is used Git

• Git is used to manage, track, and control changes in source code during software development.

  • Tracks Code History: Saves every change, so you can return to any previous version.

  • Enables Team Collaboration: Multiple developers can work on the same project without overwriting each other’s work.

  • Supports Branching: Developers can create separate branches to work on new features safely.

  • Data Integrity: Git uses cryptographically secure hashing (SHA-1) to ensure the integrity of the code and its change history, protecting against accidental or malicious corruption.

Common Git Commands:

Git Essential Commands

• git init

  Initialises a new git repository in the current directory.

  

  git status

  Shows the status of changes as untracked, modified, or staged in the working directory.

  

  git add

  Stages a change, adding a file or changes in a file to the staging area, which is the next snapshot to be committed.

  

  git Commit

  Saves the staged snapshot to the project history with a descriptive message

  

  git log

  Displays a log of all commits in the current branch history.

  

  Basic Developer Workflow Using Git

  Creating a local repository and initialising it with git

cd my_project
git init

• Clone an existing remote repository (alternative)

git clone https://github.com
cd repository_name

• Create a new branch

git checkout -b feature/my-new-feature

• Make changes

  • Modify files, add now ones, or delete old ones with in your project directory using your preferred code editor

  • Stage your changes

git add . //To add all files to staging
git add specific_file.txt   // To add specific style

• Commit your changes

git commit -m "Initial commit"

• Push your changes

git push --set-upstream origin feature/my-new-feature

• Create a PR

  • Go to remote repository’s website (GitHub or gitlab) and open a pull request to merge your feature branch in to the main branch. This allows team members to review your code before it is integrated

• Merge the PR

  • After review and approval, merge the pull request via the web interface

• Update your local main branch

git checkout main
git pull origin main

• This process creates a clear, traceable history of changes and facilities collaboration with in a development team.

Git Working Directory → Staging area → repository