Staging Files

Staging is Git's way of letting you choose exactly which changes go into your next commit. Think of it as a "preparation area" — you move changes from your working directory to the staging area before committing them. This gives you fine-grained control over your project history.

The Three Areas of Git

Understanding these three areas is the key to mastering Git:

1. Working Directory — Your actual files on disk. Where you write code.
2. Staging Area (Index) — A preview of what will go into the next commit.
3. Repository (.git) — The permanent history of all committed snapshots.

# The flow:
# Edit files -> git add -> git commit
# Working Dir -> Staging Area -> Repository

Staging Files with git add

# Stage a specific file
git add index.html

# Stage multiple specific files
git add index.html style.css app.js

# Stage all files in a directory
git add src/

# Stage ALL changes (new, modified, deleted)
git add .

# Stage all changes (alternative)
git add -A
# or
git add --all

Checking What's Staged

# See status — staged files appear in green, unstaged in red
git status

# Short format status
git status -s
# Output:
# M  modified-and-staged.js      (green M = staged)
#  M unstaged-changes.js         (red M = modified but not staged)
# ?? new-untracked-file.txt      (?? = untracked)
# A  newly-added-file.js         (A = newly staged)

Viewing Differences

# See what you changed but HAVEN'T staged yet
git diff

# See what you HAVE staged (ready to commit)
git diff --staged
# or
git diff --cached

# See changes in a specific file
git diff index.html

Unstaging Files

# Remove a file from staging (keep the changes in working directory)
git restore --staged index.html

# Unstage everything
git restore --staged .

# Older syntax (still works)
git reset HEAD index.html

Interactive Staging

Stage only parts of a file — useful when a file has multiple unrelated changes:

# Stage hunks interactively
git add -p

# Git will show each change and ask:
# Stage this hunk [y,n,q,a,d,s,e,?]?
# y = stage this hunk
# n = skip this hunk
# s = split into smaller hunks
# q = quit (keep what you've staged so far)

This is incredibly powerful. You might have a bug fix and a new feature in the same file — git add -p lets you commit them separately for a cleaner history.

Why Not Just Commit Everything?

Staging exists so you can create meaningful, focused commits. Instead of one giant commit with "fixed stuff and added things," you can:

1. Stage and commit the bug fix: "Fix login validation error"
2. Stage and commit the new feature: "Add password strength indicator"

Each commit tells a clear story. This makes your project history readable and makes it easy to revert specific changes later.

What's Next

You now understand staging. In the next episode, we'll make actual commits — saving your staged changes to the permanent project history.