The Three States of Git: Working Directory, Staging Area, and Repository

This is arguably the single most important concept in all of Git. Every command you will learn — `add`, `commit`, `status`, `diff`, `reset`, `checkout` — makes far more sense once you understand that Git organizes a project's files into three distinct states: the working directory, the staging area (also called the index), and the repository. Skipping this mental model is the number one reason beginners find Git confusing; mastering it is the number one reason experienced developers find Git precise and predictable.

Learning Objectives

Identify the three states a file can occupy in Git: working directory, staging area, and repository.
Explain what happens to a file as it moves between these three states.
Understand the staging area's role as an intentional 'preview' of the next commit.
Connect this mental model to the commands (add, commit) used to move between states.

Key Terms to Know Before Learning The Three States of Git

Working Directory: The actual folder on your file system containing your project's files, where you edit content directly.
Staging Area (Index): An intermediate holding area where Git tracks exactly which changes will be included in the next commit.
Repository (.git directory): The database where Git permanently stores committed snapshots of your project's history.
Modified: A file's state when it has been changed in the working directory but not yet staged.
Staged: A file's state when its changes have been added to the staging area, marking them ready to be included in the next commit.
Committed: A file's state when its staged changes have been permanently saved as part of a snapshot in the repository's history.

How The Three States of Git Actually Works

Think of Git's three states as three physical locations a change to a file passes through before it becomes permanent history:

**1. Working Directory** — This is simply your project folder as it exists on disk right now. When you open a file in your editor and type new code, you are modifying the working directory. Git is watching this folder, but nothing here is 'safe' yet — it's just the current, editable state of your files, no different from any other folder on your computer.

**2. Staging Area (Index)** — This is the concept that trips up most beginners coming from other tools, because many other version control systems don't have an equivalent. The staging area is a separate, intermediate space where you tell Git exactly which changes — potentially just some of the changes in some of the files — you want to include in your *next* commit. Running `git add <file>` copies the current state of that file from the working directory into the staging area. Crucially, this means you can modify five files, but stage only two of them, giving you precise control over what goes into each commit rather than being forced to save everything at once.

**3. Repository** — This is the permanent historical record, stored inside the hidden `.git` folder. Running `git commit` takes everything currently in the staging area and saves it as a new, permanent snapshot in the repository's history, along with an author, timestamp, and commit message. Once committed, that snapshot becomes part of Git's permanent (though still editable via advanced commands) history.

Here's the full lifecycle in practice: you edit a file (working directory changes) → you run `git add` to move that change into the staging area (staged) → you run `git commit` to move the staged changes permanently into the repository (committed). A file can be in different states simultaneously in a sense — for example, you can stage a first set of changes, then keep editing the same file further, so that the file now has both staged changes (waiting for the next commit) and additional unstaged modifications in the working directory at the same time.

This three-stage model is exactly what commands like `git status` report on (which files are modified, staged, or untracked), what `git diff` compares (working directory vs. staging area, or staging area vs. last commit), and why `git add` exists as a distinct step from `git commit` at all — it gives you deliberate, fine-grained control over exactly what each snapshot in your history contains.

The Three States of Git: Visual Walkthrough

Draw three boxes in a horizontal row connected by labeled arrows. Box 1: 'Working Directory (edit files)'. Arrow from Box 1 to Box 2 labeled 'git add'. Box 2: 'Staging Area / Index (changes marked ready)'. Arrow from Box 2 to Box 3 labeled 'git commit'. Box 3: 'Repository (.git) — permanent snapshot history'. Add a dashed feedback arrow from Box 3 back to Box 1 labeled 'git checkout / git reset (restore files)' to show that history can also flow back into the working directory.

The Three States of Git: Quick Reference Table

State	Location	Command to Enter This State	File Status Shown by git status
Working Directory	Your project folder on disk	Simply editing/saving a file	'modified' or 'untracked'
Staging Area (Index)	Internal Git index file	git add <file>	'Changes to be committed'
Repository	.git folder (commit history)	git commit	Not shown (clean, already committed)

The Three States of Git: Command Syntax and Examples

# 1. Edit a file — this only changes the WORKING DIRECTORY
echo "console.log('hello');" >> app.js

git status
# app.js shown as "modified" (working directory change, not yet staged)

# 2. Move the change into the STAGING AREA
git add app.js

git status
# app.js shown under "Changes to be committed" (now staged)

# 3. Move the staged change into the REPOSITORY (permanent history)
git commit -m "Add hello log to app.js"

git status
# working tree clean — nothing left in working dir or staging area to commit

Breaking Down the The Three States of Git Example

This sequence walks through all three states for a single file. After editing `app.js`, `git status` reports it as modified — it exists only in the working directory at this point. Running `git add app.js` moves that specific change into the staging area, and `git status` now reports it under 'Changes to be committed'. Finally, `git commit -m "..."` takes everything currently staged and writes it permanently into the repository's history as a new snapshot — after which `git status` reports a clean working tree, because there's nothing left in either the working directory or staging area that hasn't been committed.

How The Three States of Git Is Used on Real Engineering Teams

Professional developers routinely stage only some of their changed files with `git add specific-file.js` (leaving debug print statements in other files unstaged) to keep commits focused and reviewable.
Code review tools like GitHub Pull Requests display diffs based on committed snapshots — meaning changes that are only in your working directory or staging area are invisible to reviewers until you commit and push.
Interactive staging (`git add -p`), which lets you stage individual chunks (hunks) within a single file rather than the whole file, is a common technique senior engineers use to write cleaner, more atomic commits.
CI/CD pipelines trigger builds based on committed, pushed changes in the repository — uncommitted working directory or staging area changes never reach these automated systems.

The Three States of Git Interview Questions and Answers

Q1. What are the three states of a Git-tracked file?

Working directory (the file as it currently exists on disk, potentially modified), staging area or index (a snapshot of changes marked to be included in the next commit), and repository (the permanent, committed history stored in the .git folder).

Q2. Why does Git have a separate staging area instead of committing changes directly?

The staging area gives developers precise control over exactly what goes into each commit. It allows staging only some files or even parts of files, enabling focused, atomic commits rather than being forced to commit every single change in the working directory at once.

Q3. What is the difference between 'modified' and 'staged' in Git terminology?

'Modified' means a tracked file has changes in the working directory that have not yet been added to the staging area. 'Staged' means those changes have been moved into the staging area via `git add` and are marked ready to be included in the next `git commit`.

The Three States of Git Quiz: Test Your Understanding

1. Which command moves a change from the working directory to the staging area?

git commit
git push
git add
git init

Answer: C. git add

Explanation: `git add` stages a file's current changes, copying them into the staging area (index) so they're marked ready for the next commit.

2. What happens when you run git commit?

Changes move from the working directory directly into the repository, skipping staging
Staged changes are saved as a permanent snapshot in the repository
The working directory is deleted
All untracked files are automatically staged

Answer: B. Staged changes are saved as a permanent snapshot in the repository

Explanation: `git commit` takes everything currently in the staging area and permanently records it as a new snapshot in the repository's history.

3. If you edit a file but never run git add, where does the change exist?

Only in the repository
Only in the staging area
Only in the working directory
Nowhere — Git deletes unstaged changes

Answer: C. Only in the working directory

Explanation: Without running `git add`, a change remains only in the working directory and is not tracked as staged; it will not be included if you run `git commit`.

The Three States of Git: Common Mistakes Beginners Make

Running git commit and expecting all edited files to be included, forgetting that only staged changes are committed.
Confusing 'staged' with 'committed' — staging is only a preview step; nothing is permanently saved until git commit runs.
Not realizing the same file can have both staged and additional unstaged changes at the same time if you keep editing after staging.
Assuming git add saves changes permanently — it only moves them to the staging area, not into the repository's history.

The Three States of Git: Exam-Ready Quick Notes

Three states, in order: Working Directory → Staging Area (Index) → Repository.
git add: working directory → staging area. git commit: staging area → repository.
The staging area exists specifically to allow selective, precise control over commit contents.

The Three States of Git: Key Takeaways

Every Git operation can be understood as moving file changes between the working directory, staging area, and repository.
The staging area is what makes Git commits deliberate and precise, rather than an all-or-nothing save operation.
Understanding this model makes commands like git status, git diff, git add, and git commit intuitive rather than mysterious.

Frequently Asked Questions About The Three States of Git

Q1. What are the three states of Git in simple terms?

Working directory is where you edit your files right now. Staging area is a waiting room where you put the specific changes you want to save next. Repository is the permanent history where committed snapshots live forever.

Q2. Why does Git need a staging area at all?

The staging area lets you choose exactly which changes go into each commit, even if you've modified many files. This means you can create focused, clean commits instead of being forced to save every change in your project at once.

Q3. What is the difference between the staging area and the repository?

The staging area is temporary and only holds a preview of the next commit — it gets cleared out (folded into history) every time you commit. The repository is permanent; once a commit is made, that snapshot stays in the project's history.

Q4. Can a file be both staged and modified at the same time?

Yes. If you stage a change with git add and then edit the file again without staging the new edit, Git tracks two separate states for that file: the staged version (waiting for commit) and the newer unstaged modification in the working directory.

Q5. What command shows which state my files are currently in?

git status is the primary command for this — it clearly labels files as untracked, modified (unstaged), or staged ('Changes to be committed'), which is covered in detail in the next lesson.

Summary

Git organizes every tracked file into three states: the working directory (your actual editable project files on disk), the staging area or index (an intermediate space where changes are marked ready for the next commit), and the repository (the permanent, committed history stored in the .git folder). `git add` moves changes from the working directory into the staging area, and `git commit` moves staged changes permanently into the repository as a new snapshot. This three-stage model is the foundation for understanding virtually every other Git command, and internalizing it is the single most valuable step a Git beginner can take.