Chapter 1.3

The Three Trees

The foundational mental model of Git. If you understand these three areas, you will never casually destroy your work again.

The Three Trees Metaphor

1

Working Directory

Your sandbox. Unsaved state.

index.js (modified)
2

Staging Area

The index. Pre-commit queue.

.git/index
3

Repository

Saved history timeline.

.git/objects/

1. Working Directory

This is what you literally see in your code editor. It holds the actual files in your filesystem. Changes here are untracked until you tell Git about them.

2. Staging Area (The Index)

A virtual queue (stored inside a single file at .git/index). When you run git add, you are copying the current state of a file from the Working Directory into here, queuing it up for the next snapshot.

3. Repository

The actual version history (stored in .git/objects/). When you run git commit, Git takes everything inside the Staging Area, wraps it in a permanent snapshot, and saves it forever.

Behind the Scenes

Notice what folders Map to what "Tree":

my-project/Works as Tree 1 (Working Dir)
index.js
.git/
indexIs literally Tree 2 (Staging Area)
objects/Stores Tree 3 (Repository)

Gotcha: 'I added the file, but git commit didn't save my new changes!'

This is the most common beginner mistake. Let's trace the problem:

  1. git add index.js // copies line 1 into Staging Area
  2. Modify index.js adding line 2 // only modifies Working Directory!
  3. git commit -m "added stuff" // only captures what is in Staging!

Git commits exactly what is in the Staging Area. If you edit a file after adding it to staging, you have to run git add again to update the staging queue!