Module 2: The Git Mental Model

🎯 What you'll learn: The three areas of Git (Working Directory → Staging Area → Repository), what a commit really is, and how Git organises your project's history.

⚠️ This is the most important module. Everything in Git makes sense once you understand this mental model. Take your time here!

---

The Big Idea — Three Areas

Git organises your work into three areas. Every file in your project lives in one of these areas at any given time:

┌──────────────────────────────────────────────────────────────────┐
│                        Git's Three Areas                         │
│                                                                  │
│  ┌──────────────┐    git add     ┌──────────────┐   git commit  ┌──────────────┐
│  │   WORKING    │──────────────>│   STAGING    │─────────────>│  REPOSITORY  │
│  │  DIRECTORY   │               │    AREA      │              │   (History)  │
│  │              │               │  (Index)     │              │              │
│  │  Your files  │               │  "Ready to   │              │  Permanent   │
│  │  as you see  │               │   save"      │              │  snapshots   │
│  │  them        │               │              │              │  (commits)   │
│  └──────────────┘               └──────────────┘              └──────────────┘
│                                                                  │
│  📝 You edit here              📦 You stage here               📸 Saved forever │
└──────────────────────────────────────────────────────────────────┘

Let's understand each one:

Area	What It Is	Analogy	Git Command
Working Directory	Your project folder — the files you see and edit	Your desk where you're working	(just edit normally!)
Staging Area (Index)	A preparation zone — files you've marked as "ready to save"	Your shopping cart before checkout	git add
Repository	The permanent history — saved snapshots of your project	Your purchase history / receipt archive	git commit

---

The Analogy — Online Shopping 🛒

This is the best way to understand Git's three areas. Imagine you're shopping online:

Step 1: Browse the Store (Working Directory)

You're browsing an online store. You look at shirts, try different sizes, compare colours. Nothing is committed yet — you're just exploring and making choices.

In Git: This is your Working Directory. You create files, edit them, delete them. Git sees the changes but hasn't saved anything yet.

Step 2: Add to Cart (Staging Area)

You find a shirt you like and click "Add to Cart". It's not purchased yet — it's just marked as "I want this." You can still remove it, add more items, or change your mind.

In Git: When you run git add, you're putting files into the Staging Area (the cart). You're saying "these changes are ready to be saved." You can add more files, remove some, or change your mind before the next step.

Step 3: Checkout / Pay (Commit)

You click "Place Order". Done! The purchase is recorded permanently — it appears in your order history with a timestamp, order number, and details.

In Git: When you run git commit, you're saving a permanent snapshot. It gets a unique ID, a timestamp, your name, and a message describing what changed. This is saved forever in the Repository.

The Full Flow

graph LR
    subgraph wd["🛍️ Browse Store<br/>(Working Directory)"]
        A["Look at items<br/>Try things<br/>Edit files"]
    end

    subgraph sa["🛒 Shopping Cart<br/>(Staging Area)"]
        B["Items ready<br/>to purchase<br/>(git add)"]
    end

    subgraph repo["🧾 Order History<br/>(Repository)"]
        C["Purchase recorded<br/>permanently<br/>(git commit)"]
    end

    A -->|"git add<br/>(add to cart)"| B
    B -->|"git commit<br/>(checkout)"| C

    style wd fill:#1a1a2e,stroke:#ff66ff,color:#fff
    style sa fill:#1a1a2e,stroke:#ffff66,color:#fff
    style repo fill:#1a1a2e,stroke:#66ff66,color:#fff

Why a Staging Area? Why Not Just Save Directly?

Good question! The staging area gives you control. Imagine you changed 5 files, but only 3 of those changes are related. You can:

1. Stage just the 3 related files (git add file1 file2 file3)
2. Commit them with a clear message ("Added café menu items")
3. Then stage the other 2 files separately
4. Commit those with a different message ("Fixed typo in header")

This keeps your history clean and meaningful — each commit tells a clear story.

Without Staging	With Staging
"Changed a bunch of stuff"	"Added café menu items"
One messy commit	+ "Fixed typo in header"
Hard to find what changed	Each commit = one clear purpose

💡 Shopping cart analogy: You wouldn't buy everything in the store at once. You pick what you want, review your cart, then checkout. Git works the same way.

---

What is a Commit?

A commit is a snapshot of your entire project at a specific point in time. Think of it like a photo — not a video.

What's Inside a Commit?

Every commit contains:

Part	What It Is	Example
Snapshot	A copy of ALL your tracked files at that moment	All 47 files as they were at 3:15 PM
Message	A description YOU write	"Added coffee prices to menu"
Author	Who made the commit	Sutheesh susanth@...
Timestamp	When it was made	2026-04-06 15:15:00 NZST
Hash (ID)	A unique identifier (40 characters)	a3f7b2c...
Parent	Pointer to the previous commit	9e1d4a8...

┌─────────────────────────────────────────┐
│            Commit: a3f7b2c              │
├─────────────────────────────────────────┤
│  Message:  "Added coffee prices"        │
│  Author:   Sutheesh                     │
│  Date:     2026-04-06 15:15 NZST        │
│  Parent:   9e1d4a8                      │
│                                          │
│  📸 Snapshot of ALL files:              │
│     ├── menu.md        (changed ✏️)     │
│     ├── index.html     (unchanged)      │
│     └── style.css      (unchanged)      │
└─────────────────────────────────────────┘

Snapshots, Not Diffs

This is a common misconception. Git does NOT just store "what changed" (diffs). It stores a complete snapshot of every file at that moment.

Approach	How It Stores	Analogy
Diffs (what Git does NOT do)	Only stores the changes between versions	A recipe that says "add more salt" (useless without the original)
Snapshots (what Git DOES)	Stores a complete copy of all files	A complete photo of the finished dish

💡 Photo album analogy: Git is like a photo album. Each commit is a photo of your entire project. Flip back to any photo and you see EVERYTHING as it was at that moment — not just what changed.

(Technically, Git is smart about storage — if a file hasn't changed, it stores a pointer to the previous version instead of a duplicate. But conceptually, think of each commit as a complete snapshot.)

---

How Commits Form a Timeline

Commits are linked together — each one points back to its parent (the previous commit). This creates a timeline:

Time ──────────────────────────────────────────────>

┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ Commit 1 │───>│ Commit 2 │───>│ Commit 3 │───>│ Commit 4 │
│ "Initial │    │ "Added   │    │ "Fixed   │    │ "Added   │
│  setup"  │    │  menu"   │    │  typo"   │    │  prices" │
│ 9e1d4a8  │    │ b5c3f71  │    │ 2d8e9a3  │    │ a3f7b2c  │
└─────────┘    └─────────┘    └─────────┘    └─────────┘
                                                    ↑
                                                   HEAD
                                              (you are here)

gitGraph
    commit id: "Initial setup"
    commit id: "Added menu"
    commit id: "Fixed typo"
    commit id: "Added prices"

What is HEAD?

HEAD is a pointer that says "you are here" — it points to your current position in the timeline. Usually, HEAD points to the latest commit on your current branch.

Think of HEAD like the "You Are Here" marker on a shopping mall map 📍. It tells Git where you currently are in the project's history.

---

Putting It All Together — The Full Picture

Here's the complete mental model of how Git works:

graph TD
    subgraph local["Your Computer"]
        WD["📝 Working Directory<br/>(your files as you see them)"]
        SA["📦 Staging Area<br/>(ready to save)"]
        REPO["📸 Repository (.git)<br/>(permanent history)"]
    end

    subgraph remote["GitHub (Remote)"]
        GH["☁️ Remote Repository<br/>(backup + sharing)"]
    end

    WD -->|"git add"| SA
    SA -->|"git commit"| REPO
    REPO -->|"git push"| GH
    GH -->|"git pull"| WD

    style local fill:#1a1a2e,stroke:#66ffff,color:#fff
    style remote fill:#0a1a0a,stroke:#66ff66,color:#fff

The Commands Mapped to the Mental Model

You Want To...	Command	What It Does (Mental Model)
See what's changed	git status	Shows which area each file is in
Mark files as "ready"	git add	Moves from Working Directory → Staging Area
Save a snapshot	git commit	Moves from Staging Area → Repository
Send to GitHub	git push	Copies from Repository → Remote
Get from GitHub	git pull	Copies from Remote → Working Directory
See history	git log	Shows all commits in the Repository
See differences	git diff	Compares Working Directory vs last commit

---

A Day in the Life — The Full Workflow

Let's trace through a real example — you're updating the Cloud Café menu:

Step 1: Edit a File (Working Directory)

You open menu.md and add a new coffee:

## Hot Drinks
- Flat White — $5.00
- Long Black — $4.50
- Mocha — $6.00          ← NEW: you just added this line

Git notices the change but hasn't done anything yet. If you run git status:

Changes not staged for commit:
  modified:   menu.md          ← Git sees the change (red)

The file is in the Working Directory — changed, but not staged.

Step 2: Stage the File (git add)

You decide this change is ready. You run:

git add menu.md

Now git status shows:

Changes to be committed:
  modified:   menu.md          ← Staged and ready (green)

The file moved to the Staging Area — in the shopping cart, ready to checkout.

Step 3: Commit (git commit)

You save the snapshot with a message:

git commit -m "Added Mocha to hot drinks menu"

Git creates a permanent snapshot:

[main a3f7b2c] Added Mocha to hot drinks menu
 1 file changed, 1 insertion(+)

The change is now in the Repository — saved forever with a unique ID, your name, and timestamp.

Step 4: Push to GitHub (git push)

git push

The commit is now on GitHub too — backed up and (if you have Actions) automatically deployed!

The Journey of Your Change

"Added Mocha" line in menu.md

  📝 Working Directory     You typed the new line
         │
         │  git add
         ▼
  📦 Staging Area          Marked as "ready to save"
         │
         │  git commit -m "Added Mocha..."
         ▼
  📸 Local Repository      Saved permanently (commit a3f7b2c)
         │
         │  git push
         ▼
  ☁️ GitHub (Remote)       Backed up + triggers deploy
         │
         │  GitHub Actions
         ▼
  🌐 Live Website          Mocha appears on aguidetocloud.com!

---

Checking File Status — The Lifecycle

Every file in your Git project is in one of these states:

stateDiagram-v2
    [*] --> Untracked: New file created
    Untracked --> Staged: git add
    Staged --> Committed: git commit
    Committed --> Modified: Edit the file
    Modified --> Staged: git add
    Staged --> Committed: git commit

State	What It Means	Colour in git status
Untracked	Git doesn't know about this file yet	Red (new file)
Modified	File changed since last commit	Red
Staged	File is in the staging area, ready to commit	Green
Committed	File is saved in the repository	Doesn't appear (clean)

When git status shows nothing? That means everything is committed — your working directory is "clean."

---

Common Misconceptions

❌ Misconception	✅ Reality
"Git saves every change automatically"	No — YOU decide when to save (commit). Git only tracks what you tell it to.
"git add saves my file"	No — git add just stages it (puts it in the cart). git commit actually saves it.
"A commit stores only what changed"	Conceptually, a commit is a full snapshot of all tracked files. Git is smart about storage, but think of it as a complete photo.
"I need internet to use Git"	No! Git works 100% offline. Internet is only needed for push and pull (talking to GitHub).
"If I delete a file, it's gone from Git"	No! Previous commits still have the old version. You can always go back in time.

---

✅ Module 2 Summary

┌────────────────────────────────────────────────────────┐
│                    Module 2 Recap                       │
├────────────────────────────────────────────────────────┤
│                                                         │
│  📝 Working Directory — your files, where you edit     │
│       │                                                 │
│       │ git add (add to cart)                           │
│       ▼                                                 │
│  📦 Staging Area — files marked "ready to save"        │
│       │                                                 │
│       │ git commit (checkout/pay)                       │
│       ▼                                                 │
│  📸 Repository — permanent snapshots (commits)         │
│       │                                                 │
│       │ git push (send to GitHub)                       │
│       ▼                                                 │
│  ☁️ Remote — backup on GitHub                           │
│                                                         │
│  📸 Commit = snapshot + message + author + timestamp   │
│  📍 HEAD = "you are here" pointer                       │
│  🔗 Commits form a chain (each points to its parent)  │
│                                                         │
│  ➡️ Next: Module 3 — Hands-on! Create your first repo │
└────────────────────────────────────────────────────────┘

---

🧪 Module 2 Quiz

Test your understanding! Click each question to reveal the answer.

Q1: What are the three areas in Git, and what does each one do?

1. Working Directory — your project files as you see and edit them
2. Staging Area (Index) — a preparation zone for files you've marked as "ready to save" using git add
3. Repository — the permanent history of saved snapshots (commits), created with git commit

Q2: You've edited 3 files but only want to save changes to 2 of them. How?

Use git add to stage only the 2 files you want:

git add file1.md file2.md
git commit -m "Updated these two files"

The third file stays in the Working Directory — changed but not committed. This is exactly why the Staging Area exists!

Q3: What's the difference between git add and git commit?

git add = puts files in the Staging Area (like adding items to a shopping cart). Nothing is saved yet. git commit = takes everything in the Staging Area and saves it permanently as a snapshot (like clicking "Place Order"). This creates a commit with a unique ID, message, author, and timestamp.

Q4: What does HEAD mean in Git?

HEAD is a pointer that says "you are here" — it points to your current position in the commit history. Usually, HEAD points to the latest commit on your current branch. Like the "You Are Here" marker on a mall map.

Q5: A commit only stores the lines that changed. True or false?

False! A commit stores a complete snapshot of ALL tracked files — like a photo of the entire project, not just the changes. (Git is smart about storage efficiency, but conceptually it's a full snapshot.)

---

➡️ What's Next?

In Module 3: Your First Repository, you'll put this mental model into practice! You'll create a repository, make changes, stage them, commit them, and see your history — all with real commands on your machine.