GitStaging Changes (git add)

Staging Changes (git add)

git add moves changes from your working directory into the staging area (also called the index). Nothing is recorded in Git history yet — that happens with git commit. Think of staging as “picking out” which of your current changes you want in the next commit. The split between these two steps is what makes Git so flexible for crafting clean, atomic history.

The most common forms

Day-to-day staging

Bash
# One file
git add path/to/file.js

# Several files
git add file1.js file2.js styles.css

# Everything in the current directory (recursive)
git add .

# Everything in the entire repo (rooted at the top)
git add -A

# Everything in src/, recursively
git add src/
git add . vs git add -A

  • git add . — adds new and modified files under the current directory. Deletions outside this directory are not staged.

  • git add -A (same as --all) — adds new, modified, AND deleted files across the whole repo.

  • git add -u — adds modified and deleted files (but NOT new untracked ones).

Modern Git
On Git 2.0+, `git add .` and `git add -A` behave the same as long as you run them from the repo root. The distinction only matters when you are in a subdirectory.
Interactive staging — stage only parts of a file

Sometimes you have changed two unrelated things in the same file and want to commit them separately. git add -p (for patch) walks you through each chunk and asks whether to stage it.

Patch mode

Bash
git add -p

# For each "hunk" Git asks:
#   Stage this hunk [y,n,q,a,d,e,?]?
# y - yes, stage this hunk
# n - no, skip it
# q - quit, do not stage this or any remaining
# a - stage this and all later in this file
# d - skip this and all later in this file
# s - split into smaller hunks
# e - edit the hunk manually (advanced)
# ? - help
Tip
`git add -p` is the single biggest skill that distinguishes Git beginners from intermediate users. Every commit you ship at work could probably be cleaner if you used it.
Unstaging

If you staged something by accident, undo it without losing your edits:

Move a file back out of staging

Bash
# Modern Git
git restore --staged file.js

# Older Git
git reset HEAD file.js

# Unstage everything
git reset
# (your working-tree changes are still there)
What gets ignored?

  • Files matching .gitignore are not staged by git add ..

  • You can force them with git add --force ignored-file.log.

  • Files that are already tracked are not affected by .gitignore — adding a pattern there does not remove a file Git is already tracking.

Adding deleted files

If you delete a file with rm (not git rm), Git sees it as a deletion. Stage the deletion the same way you stage any other change:

Bash
rm old-file.txt
git status     # shows: deleted: old-file.txt
git add old-file.txt   # stages the deletion
# Or:
git add -A     # stages every change including deletions
Dry run — preview what add would do

Bash
git add -n .       # or: git add --dry-run .
# would add 'src/new.js'
# would add 'src/util.js'
# add 'styles.css'
Adding a renamed file

Git detects renames by comparing content. If you rename a file with your OS and then git add both the old and new paths (use -A), Git records it as a rename automatically — no special command needed.

Why this two-step (add then commit) design?

  • You can edit many things, then commit them separately to keep history clean.

  • You can review exactly what is about to be committed (git diff --staged) without surprises.

  • You can stage part of a file with -p for surgical commits.

  • Other VCS tools auto-commit everything modified — Git gives you a thoughtful pause.

Common mistakes

  • Forgetting to git add before git commit — your commit will include only what is already staged. New edits are left out.

  • Staging too much at once — gets harder to write a focused commit message and harder to revert later.

  • Adding files that should be ignored (build outputs, node_modules, .env) — set up .gitignore first to prevent this.

  • Confusing git add with git commit — add only stages; nothing is in history until you commit.

Warning
Watch out when you blindly run `git add .` — you might stage secrets, credentials, or huge binaries. Always check `git status` first.
Tip
Develop a rhythm: edit → `git status` → `git add -p` → `git status` → `git diff --staged` → `git commit -m "..."`. It feels slow at first but becomes very fast and prevents almost every common mistake.