git add
git add moves changes from your working tree to the staging area — the snapshot that becomes the next commit. The staging area is what makes Git crafted commits possible instead of a wall of mixed changes.
add, patch mode, restore, unstage
EXAMPLE
# 1) The three areas # working tree ── your files on disk # staging area ── what will be in the next commit (also called 'the index') # repository ── committed history # # git add moves working tree -> staging. # 2) Status — see what's where git status # Shows: # Untracked — new files, never staged # Modified — changes in working tree, not staged # Staged — added; ready for the next commit # 3) Add a specific file git add src/login.js # Add a directory recursively git add src/ # Add EVERYTHING — careful with this in big repos git add . # everything from current dir down git add -A # entire repo, including deletions outside cwd git add -u # only update tracked files (no untracked) # 4) Dry run — see what 'add .' would do without doing it git add . --dry-run git add -An . # 5) Interactive add — pick files git add -i # Menu: status / update / revert / patch / diff / quit / help # 6) Patch mode — stage SOME hunks of a file git add -p src/login.js # For each hunk, choose: # y — stage this hunk # n — skip # s — split into smaller hunks # e — edit hunk manually (advanced) # q — quit, keep what's already staged # This is how you make focused, reviewable commits when you've made unrelated changes in one sitting. # 7) Diff what you've staged git diff # working tree vs staging git diff --staged # staging vs last commit (a.k.a. --cached) git diff HEAD # working tree vs last commit (both modified and staged) # 8) Unstage — move back from staging to working tree git restore --staged src/login.js # Git 2.23+ git reset HEAD src/login.js # older form # Working tree changes are kept; just the stage is reverted. # 9) Discard working-tree changes (destructive — be sure) git restore src/login.js # working tree -> what's in staging or HEAD git checkout -- src/login.js # older form # These DELETE uncommitted changes. There is no undo from here for those edits. # 10) Add new files but not deletions (or the inverse) git add --ignore-removal . # adds new + modified, not deletions git add -u # only tracked file updates (incl. deletions) # 11) .gitignore — keep noise out of the staging area # .gitignore (committed) vs .git/info/exclude (local only) node_modules/ .env .env.* dist/ coverage/ *.log .DS_Store .idea/ .vscode/* !.vscode/extensions.json # negation — keep one specific file # Already-tracked files are NOT ignored retroactively: git rm --cached path/to/already-tracked # 12) Force-add an ignored file (rare but useful for shared assets) git add -f dist/critical.bundle.js # 13) Verify before commit git status -s # short format git diff --staged --stat # file-level summary of staged changes # 14) End-to-end echo 'feature: add login' > NOTES.md git status # NOTES.md is Untracked git add NOTES.md # now Staged git diff --staged # shows what will be committed git commit -m 'docs: add login notes' git log --oneline -n 1 # 15) Crafted-commit workflow (the real reason patch mode exists) git status # You see 3 unrelated changes in one file: a typo fix, a new feature, and a debug print. git add -p src/login.js # stage the typo fix → y # stage the new feature → n (will be a separate commit) # stage the debug print → n (don't even commit; restore later) git commit -m 'fix: typo in login error message' git add -p src/login.js # stage the new feature → y git commit -m 'feat: remember-me checkbox' git restore src/login.js # discard the debug print # 16) Common bugs # • git add . on first commit → accidentally includes .env or node_modules → use .gitignore FIRST # • Editing a file after staging — the new edits are NOT in the upcoming commit # Fix: git add the file again, or git diff to confirm # • git reset HEAD~ — that's HISTORY rewrite, not unstage. Use git restore --staged instead. # • git checkout -- file inside a directory — discards uncommitted work; use git restore for clarity # • Force-adding .env — credentials in git history; once pushed, ROTATE them
Why it matters
Treat the staging area as a draft of the next commit, not a buffer. git add -p turns a chaotic working tree into a clean sequence of focused commits, which is the difference between a reviewable history and a guessing game six months later.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Example
git add file.txt git add . # everything in CWD git add -p # review hunks one by oneTry it Yourself »
Exercise
Stage every modified file.
git add
A single dot.
Discussion
Loading…