Staging with git add
Beginner Git CLI VS Code UI IntelliJ UI
Why this matters
git add is where you decide what history will say. Stage everything blindly and your commits become "Tuesday's stuff": hard to review, hard to revert, and occasionally containing a secret. Stage deliberately and each commit tells one story. The command is simple; the habit is the skill.
The forms
| Command | Stages | Use it for |
|---|---|---|
git add docs/faq.md |
one file (new, modified or deleted) | the normal case |
git add docs/ |
every change under a folder | a documentation reorganization |
git add . |
every change in the current folder and below: new, modified and deleted files (ignored files excluded) | "commit everything I did", after reading git status |
git add -A |
the same for the whole repository, wherever you are | same, from a subfolder |
git add -u |
modified and deleted tracked files only; no new files | updating without picking up stray new files |
git add -p |
interactively, hunk by hunk | committing part of a file |
git add on an untracked file starts tracking it; on a modified file it copies the new content to the staging area; on a deleted file it stages the deletion. The word "add" is historical; think "stage".
Everything, carefully
$ git status -s M README.md
M docs/faq.md
?? docs/notes.md$ git add .
$ git status -sM README.md
M docs/faq.md
A docs/notes.mdThe M moved to the first column (staged) and the untracked file became A (added). Whatever git status listed before, git add . staged. That is why the status comes first: if the list contains something that does not belong (a stray file, a test data change), stage files individually instead.
Part of a file
You fixed a typo and drafted a new section in the same file, and want to commit the typo fix now. git add -p walks through the file's hunks and asks about each:
$ git add -p README.mddiff --git a/README.md b/README.md
index 19ed536..6516ba6 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
# Trailguide
-A tiny command-line program that prints hiking trail information for the **Northwind Trails** guide.
+A small command-line program that prints hiking trail information for the **Northwind Trails** guide.
It exists so that people learning Git have something realistic to practice on: documentation to edit,
data to update, a small program to run, and tests that can pass or fail.
(1/1) Stage this hunk [y,n,q,a,d,e,p,?]? Answer y to stage the hunk, n to skip it, s to split a large hunk into smaller ones, q to stop. The file ends up both staged (the hunks you said yes to) and modified (the rest), which is the "both groups" situation from lesson 5.1, on purpose.
Unstaging
Staged the wrong thing? Take it back out; the edit stays in the working tree:
$ git restore --staged docs/notes.mdgit status prints this exact hint next to every staged file. Older tutorials use git reset HEAD <file>, which does the same.
In the tools
Everything above. A habit worth building: git add <file> for each file you mean, then git status to confirm, then git diff --staged before committing.
- In Source Control, hover a file under Changes and click its + (Stage Changes). It moves to Staged Changes.
- The + next to the Changes heading stages all (
git add -A). - To stage part of a file: open its diff, select lines in the right-hand pane, right-click → Stage Selected Ranges (or Stage Change on a single hunk from the gutter marker).
- To unstage: the − next to a staged file, or Unstage All Changes on the heading.
By default IntelliJ hides the staging area: in the Commit tool window, every file you tick is included in the commit, untracked files sit under Unversioned Files until you tick them (which adds them), and there is no separate staged state. That is equivalent to staging at commit time.
If you enable Settings → Version Control → Git → Enable staging area, the window gains Staged and Unstaged groups with + icons, matching the terminal exactly. Partial staging: open the diff (Ctrl+D) and use the checkboxes in the gutter to include or exclude hunks.
There is no staging on the web: editing a file in the browser and pressing Commit changes stages and commits it in one step, to the branch you choose. For anything involving choice (several files, part of a file), work locally.
Same: the web editor's Commit changes… button stages and commits at once. github.dev (press .) shows a Source Control view like VS Code's, with staging, but commits go straight to the remote branch.
Common mistakes
- Editing after staging. The commit takes the staged version.
git statusshows the file in both groups;git addagain. git addon a folder while a generated subfolder sits inside it. Check the status; add the pattern to.gitignore.- Using
git restore <file>to unstage. Without--stagedit discards the edit. The hint ingit statushas the right form. - Staging a deletion by accident with
git add .after deleting a file you meant to keep.git restore --staged <file> && git restore <file>brings it back before the commit.
Try it yourself
Goal: turn one messy working tree into two clean commits.
- In the playground, edit
README.md(one word), add a line todocs/faq.md, and createdocs/notes.mdwith a line. - Stage only the FAQ and commit it with a
docs:message. - Stage the README and commit it separately.
- Leave
docs/notes.mduntracked; confirm withgit status -sandgit log --oneline -2.
Expected result: two commits, each touching one file; ?? docs/notes.md still in the status.
Show solution
$ git add docs/faq.md
$ git commit -m "docs: add FAQ entry"
$ git add README.md
$ git commit -m "docs: reword README intro"
$ git status -s?? docs/notes.md