The Staging Area in Depth

The staging area is the most powerful and most underused part of Git. Most beginners treat it as a formality — “just run git add . to stage everything and move on.” But the staging area exists specifically so you can build commits that are focused, intentional, and easy to read in history. This lesson covers the tools that make that possible.

Staging individual files vs. everything

You already know two ways to stage:

git add pine-ridge.txt          # stage one file
git add .                        # stage everything in the current directory

A third option — stage multiple specific files in one command:

git add pine-ridge.txt summit-challenge.txt river-canyon.txt

Choose based on what belongs in the commit. If you are fixing a bug in one file and starting a feature in another, stage only the bug fix file and commit it before touching the feature work.

Staging partial changes: git add -p

Sometimes you have made several changes to one file and only want to stage some of them. git add -p (patch mode) lets you interactively choose which hunks (sections of a diff) to stage.

git add -p pine-ridge.txt

Git splits the file’s changes into hunks and shows each one, asking what to do:

@@ -1,3 +1,5 @@
 Tour notes for Pine Ridge Loop
+Best time to visit: spring or fall
 Difficulty: Moderate
+Bring trekking poles

Stage this hunk [y,n,q,a,d,s,?]?

The most common responses:

Key	Action
`y`	Stage this hunk
`n`	Skip this hunk (do not stage it)
`s`	Split this hunk into smaller pieces
`q`	Quit — stop reviewing hunks
`?`	Show help

This is how experienced developers keep commits focused even when they have made many changes across a file — they stage only the work that belongs together.

Unstaging files: git restore —staged

If you staged a file by mistake, unstage it without losing your changes:

git restore --staged pine-ridge.txt

The file moves back to “modified but not staged.” Your edits in the working tree are untouched. Only the staging area entry is removed.

To unstage everything at once:

git restore --staged .

Older Git documentation uses git reset HEAD <file> for this. Both work, but git restore --staged is the modern recommended form.

Discarding working-tree changes: git restore

If you want to throw away changes in your working tree and go back to the last staged or committed version of a file:

git restore pine-ridge.txt

Warning: This is destructive. The unsaved working-tree changes are gone — they are not staged, not in the repository, and not recoverable from Git. Only use it when you are certain you want to discard those changes. Module 04 covers all the undoing-changes commands in detail.

Checking what is staged before committing

Before committing, always review what is in the staging area:

git diff --staged

This shows the exact diff between the staging area and the last commit — what will be saved if you run git commit right now. Making this a habit before every commit prevents committing debug logs, half-finished code, or the wrong files.

The full pre-commit checklist

A reliable workflow before each commit:

git status          # what files are staged, modified, untracked?
git diff --staged   # what exactly am I about to commit?
git commit -m "..."  # commit only if the diff looks right

This takes ten seconds and prevents common mistakes.

Exercise

In your git-practice folder, edit pine-ridge.txt to add two separate changes — for example, add a line near the top and a different line near the bottom.
Run git add -p pine-ridge.txt. When Git presents the first hunk, type y to stage it. When it presents the second, type n to skip it.
Run git diff and git diff --staged. Confirm that only the staged hunk appears in --staged and the unstaged change still appears in git diff.
Practice unstaging: run git restore --staged pine-ridge.txt and then run git status to confirm the file is back in the unstaged section.
Stage the whole file with git add pine-ridge.txt, run git diff --staged to review it, then commit:

git commit -m "Add visit timing and equipment notes to Pine Ridge"

Recap

git add <file> stages a whole file. git add . stages everything in the current directory.
git add -p lets you stage individual hunks within a file, keeping commits focused even when you have made many changes.
git restore --staged <file> removes a file from the staging area without losing your working-tree changes.
git restore <file> discards working-tree changes entirely — use with caution, this is destructive.
git diff --staged shows exactly what will go into your next commit. Review it before every commit.

Next: commit messages. How you write the message matters as much as what you commit — it is the only record future readers (including you) have of why a change was made.