The Working Tree, Staging Area, and Repository

Git has three distinct areas where your code exists at different stages. Understanding these three areas is the mental model that makes every other Git concept click. Most confusion with Git — why git add exists, why commits are a two-step process — dissolves once this model is clear.

The three areas

Working Tree  →  Staging Area  →  Repository (.git)
  (edit)            (stage)           (commit)

Working Tree — The actual files in your project folder. This is where you work. When you open a file in your editor and make changes, you are working in the working tree. Git can see that these files exist and whether they have changed, but changes here do not become part of the history until you explicitly tell Git about them.

Staging Area — A holding area, also called the index, where you place changes before committing them. You stage changes with git add. Think of it as a draft of your next commit — you can stage some files but not others, review what you have staged, and make adjustments before finalizing.

Repository — The .git directory on your machine. When you run git commit, everything in the staging area becomes a permanent snapshot in the repository’s history. This is the record that never changes.

Why staging exists

The staging area exists so you can commit precisely. Without it, every change in your working tree would always go into every commit together, whether they belonged together or not.

Imagine you fixed a bug in index.html and also started a new feature in tours.html, but the feature is not finished. Without a staging area, your only options would be “commit everything” or “commit nothing.” With staging, you can add index.html to the staging area, commit just that fix, and leave tours.html unchanged for the next commit.

Real commits should be small, focused, and describe a single change. Staging makes that possible.

File states in Git

Any file in your working tree is in one of these states:

State	Meaning
Untracked	Git sees the file exists but has never been told to track it
Unmodified	Git is tracking the file and it has not changed since the last commit
Modified	Git is tracking the file and it has changed since the last commit
Staged	The file (or its changes) has been added to the staging area and will be included in the next commit

A typical workflow moves a file through these states like this:

1. You create a new file → Untracked
2. You run git add → Staged
3. You run git commit → Unmodified (it is now in the repo)
4. You edit the file → Modified
5. You run git add again → Staged
6. You run git commit → Unmodified again

Seeing the states in practice

In your git-practice folder, create two files:

echo "Tour notes for Pine Ridge" > pine-ridge.txt
echo "Tour notes for Summit Challenge" > summit-challenge.txt

Run git status:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
  pine-ridge.txt
  summit-challenge.txt

Both files are untracked. Now stage only one:

git add pine-ridge.txt

Run git status again:

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
  new file:   pine-ridge.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
  summit-challenge.txt

pine-ridge.txt has moved to “Changes to be committed” — it is staged. summit-challenge.txt is still untracked. A commit right now would include pine-ridge.txt and ignore summit-challenge.txt. This selective control is exactly what staging is for.

Exercise

1. In your git-practice folder, create two files — pine-ridge.txt and summit-challenge.txt — each with a line of text.

2. Run git status and confirm both show as untracked.

3. Stage only pine-ridge.txt:

git add pine-ridge.txt

4. Run git status again. Identify which section each file appears in and what that means.

5. Try editing pine-ridge.txt after staging it. Run git status again. You will see it appear in both “Changes to be committed” (the staged version) and “Changes not staged for commit” (the newer edit). This demonstrates that staging captures the file at a specific moment, not continuously.

Recap

• Git has three areas: the working tree (your files), the staging area (your draft commit), and the repository (permanent history in .git).
• Files move from untracked → staged → committed as you run git add and git commit.
• The staging area lets you choose exactly which changes go into each commit, making commits precise and focused.
• A staged file reflects the file at the moment it was staged — later edits to the same file show as a separate “not staged” change.
• git status shows you the state of every tracked and untracked file in your working tree.

The next lesson puts this model into action: you will stage the files in your practice repo and create your first real commit.