git status and git add: Choosing What Goes In

Learning Objectives

By the end of this lesson you will be able to:

Use git status as your primary orientation tool
Stage a single file, several files, or everything, and know when each is appropriate
Unstage a file you added by mistake
Avoid the classic git add . accidents

`git status`: The Command You'll Run Most

There is no cost to running git status. It changes nothing, breaks nothing, and answers the only question that matters at any moment: where am I, and what does Git currently see?

git status

Run it before you add. Run it after you add. Run it before you commit, and again after. Experienced Git users run it constantly — not because they're unsure, but because it's faster than being wrong.

For a compact view once you're comfortable:

git status -s

 M config/test-env.yaml
M  checklist.md
?? screenshots/bug-441.png

Two columns: the left is the staging area, the right is the working directory. M in the left column means staged; M in the right means modified but unstaged; ?? means untracked.

`git add`: Loading the Next Commit

git add copies the current content of a file into the staging area. Think of it as putting an item in a box you're about to seal and label.

One file

git add checklist.md

Precise, deliberate, and the version you should default to while learning.

Several files

git add checklist.md config/test-env.yaml

Everything under a folder

git add screenshots/

Everything, everywhere

git add .

The dot means "this directory and everything beneath it". It's fast, it's popular, and it's the source of most beginner accidents.

The `git add .` Trap

git add . stages every untracked and modified file it can find — including the ones you forgot about. This is how .env files with production credentials end up in public repositories, and how a 300 MB video of a test session ends up permanently in a project's history.

Two habits that prevent it, forever:

Write your .gitignore first, before your first commit, as covered in the previous lesson.
Run git status immediately before git add ., and read the list. If something appears that you don't recognize, stage files by name instead.

Git is happy to record exactly what you tell it to. It has no opinion about whether that was wise.

Undoing a Staging Mistake

You staged something you didn't mean to. Nothing is committed yet, so nothing is lost:

git restore --staged config/test-env.yaml

The file drops back to "modified but not staged". Your edits are completely untouched — this only removes it from the queue for the next commit.

(On Git versions older than 2.23 the equivalent is git reset HEAD <file>. You will see this form in a lot of older tutorials; it does the same thing here.)

A Realistic QA Session

git status                          # what's changed since yesterday?
git add checklist.md                # stage just the checklist update
git status                          # confirm: only checklist.md is staged
git commit -m "Add negative cases to login smoke checklist"
git status                          # confirm: clean, config still pending

Five commands, three of which are git status. That ratio is not a joke — it's what working confidently in Git actually looks like.

What git add actually changes, in the one view that shows it:

  BEFORE  git add checklist.md    AFTER  git add checklist.md
  ──────────────────────────      ──────────────────────────
  $ git status -s                 $ git status -s
   M checklist.md                 M  checklist.md
   M config/test-env.yaml          M config/test-env.yaml
  ?? screenshots/bug-441.png      ?? screenshots/bug-441.png
     ▲                            ▲
     └─ column 2: working dir     └─ column 1: staging area

  Nothing is staged. A commit     checklist.md is queued. A commit
  right now would record          now records it — and only it.
  nothing at all.

The M did not change. It moved one column to the left. That single space is the entire difference between "edited" and "will be in the next commit".

Pro Tip: If you routinely have unrelated changes in flight at once, stage and commit them one at a time as you finish each. It costs seconds now and saves whoever reads that history — very possibly you — a great deal of time later.

Key Takeaways

git status is free, safe, and the fastest way to know what Git currently sees
git add <file> stages one specific change; git add . stages everything it can find
git add . is the usual cause of committed secrets and giant files — check git status first
git status -s gives a two-column short view: left column staged, right column working directory
git restore --staged <file> unstages a file without touching your edits