Lesson
The staging area
What git add really does, why the staged version is a snapshot, and how partial staging works.
Learning objectives
- Explain that git add stages content, not files
- Understand the difference between the working and staged versions
- Use restore --staged to unstage
git add stages a snapshot
When you run git add, Git copies the current content of the file into the index as a blob. This is a point-in-time snapshot. If you edit the file afterward, the staged version does not change — you now have both a staged version and a newer modified version.
Stage exactly what you mean
You can stage some files and not others, or even parts of a file with git add -p. This lets you craft focused commits even when your working directory has several unrelated changes.
Unstaging
git restore --staged <file> removes a file from the index without touching your edits. It is the inverse of git add.
Try it yourself
Empty folder
Run git init to create a repository.
Working directory
Clean — no uncommitted changes.
Staging area
Nothing staged. Run git add.
Repository
No commits yet.
Stage a file, stage everything, then unstage — watch files move between zones.
Commands used
git init
git add app.ts
git add .
git restore --staged app.ts
git statusCommon mistakes
- • Editing a file after staging and expecting the new content to be committed.
- • Using git add . and accidentally staging secrets or build output.
Best practices
- • Review git diff --staged before committing.
- • Prefer explicit paths over git add . when the tree is messy.
Mini challenge
Stage a file, edit it again, and observe that it appears as both staged and modified.
Open the visualizer to try itSummary
- git add captures content at that instant.
- Working version and staged version can differ.
- restore --staged unstages without losing edits.