Skip to main content

The Staging Area and the Commit Cycle

What This Concept Is​

Git does not commit straight from your working tree by default. It builds the next commit from the index, also called the staging area. That extra step is what lets you choose exactly what belongs in the next snapshot.

The file-state cycle is:

  • modified: changed in working tree, not yet staged
  • staged: selected for the next commit
  • committed: stored in repository history

Why It Matters Here​

Without the index, Git becomes "save whatever happens to be in my folder right now." With the index, Git becomes a tool for deliberate commit construction. That is what makes clean history, readable review, and safe rollback possible.

Concrete Example​

Suppose one file contains two unrelated edits:

git status
git diff
git add -p app.js
git diff --staged
git commit -m "Fix input validation"
git add app.js
git commit -m "Rename UI labels"

You used the index to split one messy working session into two coherent commits.

The comparisons work like this:

  • git diff compares working tree vs index
  • git diff --staged compares index vs last commit
  • git status summarizes where each file sits in that cycle

Common Confusion / Misconception​

Misconception: git commit records every changed file in the directory.

Correction: git commit records what is staged. If a file is modified but unstaged, it stays out of that commit.

Misconception: The index is unnecessary complexity.

Correction: The index is what makes commit shaping possible. It is the difference between "record everything" and "record the next meaningful unit of work."

How To Use It​

Use the index deliberately:

  • stage only one logical change at a time
  • inspect staged content before committing
  • prefer git add -p when a file contains unrelated edits

Good routine:

  1. edit
  2. git status
  3. git diff
  4. stage intentionally
  5. git diff --staged
  6. commit

Check Yourself​

  1. What does git diff compare?
  2. What does git diff --staged compare?
  3. Why is git add -p better than git add . when changes are mixed together?

Mini Drill or Application​

In a practice repository:

  1. Modify one tracked file in two different places for two unrelated reasons.
  2. Use git add -p to stage only the first reason.
  3. Commit it with a message that describes only that change.
  4. Stage and commit the remaining change separately.
  5. Verify with git log --oneline --stat that the history tells a clean story.

Read This Only If Stuck​