git add: Staging Specific Files, Directories, and All Changes

`git add` is the command that moves changes from your working directory into the staging area — the deliberate 'select what to save' step covered conceptually in Lesson 6. This lesson focuses entirely on the practical variations of this command: staging one file, staging multiple files, staging an entire directory, and staging every change in your project at once, along with the subtle but important differences between similar-looking flags.

Learning Objectives

Stage a single specific file using git add.
Stage multiple files and entire directories at once.
Stage all changes in a project using git add . or git add -A.
Understand the difference between git add . and git add -A.

Key Terms to Know Before Learning git add

Staging (in this context): The act of using git add to mark specific working-directory changes as ready to be included in the next commit.
git add <file>: Stages the current state of exactly one specified file.
git add <directory>: Stages all changes within every file inside the specified directory, recursively.
git add . : Stages all changes (new, modified, and deleted files) in the current directory and its subdirectories.
git add -A (or --all): Stages all changes across the entire repository, regardless of the current working directory location.

How git add Actually Works

The simplest form of `git add` targets a single file:

```
git add app.js
```

This stages only the current content of `app.js`, leaving any other modified files untouched and still unstaged. This precision is exactly why the staging area exists — it lets you build a commit out of only the changes that logically belong together, even if you've been editing several unrelated files at once.

You can stage multiple specific files by listing them:

```
git add app.js style.css
```

Or stage everything inside a specific directory (recursively, including subdirectories):

```
git add src/
```

For staging everything in the project at once, two very similar-looking commands exist, and the distinction matters:

- `git add .` stages all changes (new, modified, deleted) in the **current directory and below** — if you run this from inside a subfolder, changes elsewhere in the repository (outside that subfolder) won't be staged.
- `git add -A` (or `git add --all`) stages all changes across the **entire repository**, no matter which directory you're currently in when you run the command.

In modern Git versions, `git add .` run from the repository root behaves almost identically to `git add -A`, since both would cover the entire project in that case. The difference only becomes meaningful when you run the command from inside a subdirectory rather than the project root — a subtlety that has caused real bugs in scripts and CI pipelines where the working directory wasn't what the author assumed.

An important safety habit: always run `git status` before and after staging, to confirm exactly which files you intended to stage. It's a common mistake to run a broad `git add .` and accidentally stage files you didn't mean to commit yet — such as temporary debug files, local configuration, or half-finished work — which is one reason a well-configured `.gitignore` file (covered in Lesson 13) is so important.

Finally, staging is not a one-time snapshot that locks in place — if you stage a file and then edit it again, the new edits are NOT automatically included; you'll need to run `git add` again to update the staged version with your latest changes, which is exactly the scenario that produces the 'file appears in both staged and unstaged sections' output discussed in the previous lesson.

git add: Visual Walkthrough

Draw a working directory box containing five file icons: app.js, style.css, README.md, src/utils.js, temp.log. Show three separate arrows labeled with different commands: 'git add app.js' pointing only from app.js into a staging area box; 'git add src/' pointing only from src/utils.js into the staging area; 'git add .' (run from root) pointing from ALL FIVE files into the staging area, with a callout note: 'Be careful — this stages everything, including temp.log, unless ignored.'

git add: Quick Reference Table

Command	What Gets Staged	Scope
git add app.js	Only app.js	One specific file
git add app.js style.css	Only the listed files	Multiple specific files
git add src/	Every changed file inside src/, recursively	One directory and its subdirectories
git add .	All changes in current directory and below	Current directory downward only
git add -A	All changes across the entire repository	Entire repository, regardless of current folder

git add: Command Syntax and Examples

# Stage a single file
git add index.html

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

# Stage an entire directory recursively
git add src/components/

# Stage everything from the current directory downward
git add .

# Stage absolutely everything in the repository, regardless of current folder
git add -A

# Always double-check with status before committing
git status

Breaking Down the git add Example

Each `git add` variant targets a different scope, from a single named file up to the entire repository. `git add src/components/` recursively stages every changed file within that folder, which is useful when you know your changes are logically confined to one part of a project. `git add .` and `git add -A` are the broadest options — staging everything at once — but they carry the highest risk of accidentally including unintended files, which is why running `git status` immediately afterward to review exactly what got staged is a strong habit to build early.

How git add Is Used on Real Engineering Teams

Senior engineers often deliberately avoid git add . in large projects, instead staging specific files or using interactive staging (git add -p) to build small, reviewable, logically focused commits.
Onboarding documentation at many companies explicitly warns new hires about the git add . vs git add -A distinction, since it has caused real incidents where changes outside a subdirectory were unexpectedly left out of a commit.
Pre-commit hook tools (like Husky or pre-commit) often run automatically right after staging to lint or test only the staged files, reinforcing why precise staging matters for CI efficiency.
Data science teams working with large repositories containing generated files or datasets rely heavily on precise, targeted git add commands (rather than blanket adds) combined with .gitignore to avoid bloating repository history.

git add Interview Questions and Answers

Q1. What does the git add command do?

git add moves the current state of specified changes from the working directory into the staging area (index), marking them as ready to be included in the next git commit. It does not permanently save anything to the repository's history by itself.

Q2. What is the difference between git add . and git add -A?

git add . stages all changes (new, modified, deleted files) in the current directory and its subdirectories only. git add -A stages all changes across the entire repository regardless of which directory you're currently in when you run the command. They behave identically when run from the repository's root.

Q3. If you stage a file and then edit it again, does git commit include the new edit?

No. Staging captures the file's content at the moment git add was run. If you edit the file again afterward without re-running git add, the new edit remains unstaged, and a subsequent git commit will only include the originally staged version, not the latest changes.

git add Quiz: Test Your Understanding

1. Which command stages only a single specific file called app.js?

git add all
git add app.js
git commit app.js
git status app.js

Answer: B. git add app.js

Explanation: Specifying the exact filename after git add stages only that file's current changes, leaving all other files untouched in the staging area.

2. What is the key difference between git add . and git add -A?

There is no difference, ever
git add . only affects the current directory and below; git add -A affects the whole repository
git add -A only works on remote repositories
git add . deletes untracked files

Answer: B. git add . only affects the current directory and below; git add -A affects the whole repository

Explanation: git add . is scoped to the current directory downward, while git add -A (or --all) stages changes across the entire repository regardless of your current location within it.

3. If you stage a file with git add and then modify it again, what happens?

The new changes are automatically included in the staged version
The new changes remain unstaged until git add is run again
Git automatically commits the new changes
The file becomes untracked again

Answer: B. The new changes remain unstaged until git add is run again

Explanation: Staging is a snapshot at the time git add runs. Any further edits after staging are not automatically included and require staging again to be captured in the next commit.

git add: Common Mistakes Beginners Make

Running git add . carelessly and accidentally staging temporary or sensitive files that should have been excluded via .gitignore.
Assuming git add permanently saves changes — it only stages them; nothing is permanent until git commit runs.
Forgetting to re-run git add after making additional edits to an already-staged file, resulting in an outdated version being committed.
Confusing git add . (current directory downward) with git add -A (entire repository) and being surprised when changes elsewhere in the project were left unstaged.

git add: Exam-Ready Quick Notes

git add <file> stages one file; git add <dir>/ stages an entire directory recursively.
git add . stages current directory and below; git add -A stages the whole repository regardless of location.
Staging is a snapshot at the moment of the command — later edits need to be staged again separately.

git add: Key Takeaways

git add gives you precise control over exactly which changes will be included in your next commit.
Staging entire directories or the whole project at once is convenient but carries a higher risk of including unintended changes.
Always verify what got staged using git status before committing, especially after a broad git add . or git add -A.

Frequently Asked Questions About git add

Q1. What does git add actually do?

It takes the current content of the specified file(s) or directory and copies that state into Git's staging area, marking it as ready to be included the next time you run git commit.

Q2. How do I stage all my changes at once?

Run git add . from your project's root directory to stage all changes in the current directory and below, or git add -A to stage all changes across the entire repository regardless of your current folder.

Q3. Is there a difference between git add . and git add -A?

Yes, though it's subtle. git add . only stages changes in the current directory and its subdirectories. git add -A stages changes everywhere in the repository, even outside your current directory. They behave the same only when run from the project root.

Q4. What happens if I edit a file after staging it?

The new edit is not automatically included. Git only staged the file's content at the moment git add ran. You need to run git add again on that file to update the staged version with your latest changes.

Q5. Can I undo a git add before committing?

Yes. Running git restore --staged <file> removes the file from the staging area without discarding your actual changes in the working directory — it simply un-stages it.

Summary

`git add` moves changes from the working directory into the staging area, and can be scoped narrowly (a single file), moderately (an entire directory), or broadly (the whole project via `git add .` or `git add -A`). While `git add .` and `git add -A` look similar, `git add .` only affects the current directory and its subdirectories, whereas `git add -A` stages changes across the entire repository regardless of your current location — a distinction that matters when working from inside a subfolder. Staging is a snapshot at the moment the command runs, so any further edits to an already-staged file must be staged again before they'll be included in the next commit.