Core Git 5/8

Working Tree, Staging, Repository

Git work happens across three areas: the working directory where you edit files, the staging index where you choose what goes into the next commit, and the repository where committed history lives. Typical flow is edit, stage selected changes, commit a snapshot, and repeat in small increments. Most confusion is solved by identifying which area changed.

Back to Git Concepts overview

The Three Git Areas At A Glance

Before looking at the command-by-command walkthrough, this is the simplest mental model: files start in your working tree, selected changes move into staging, and commits save that staged snapshot into repository history.

Working Tree Staging Area Local Repository (.git directory) git add git commit git restore Edit in the working tree, stage selected changes, commit into history, or restore files back from the repository.

Flow Across The Three Areas

The same three areas stay in place the whole time. What changes is which area Git is reading from or writing to: git status compares them, git add copies selected changes into the index, and git commit writes the staged snapshot into repository history.

COMMAND RUN > git status WORKING TREE Files On Disk what you edited locally M src/webhook.js M src/ui.js both edits still live only in the working tree STAGING INDEX Next Commit Snapshot what Git will package next (empty) nothing staged yet LOCAL REPOSITORY Saved History committed snapshots only commit 9fab23 last saved release snapshot repository has not changed yet compare compare git status compares working tree, index, and repository so you can see what changed where.

Partial Staging Keeps Commits Clean

Working file has mixed changes + bugfix in webhook parser + refactor variable names + optional debug logs Stage only the bugfix hunk index contains minimal safe change smaller PR, faster review, lower rollback risk
git add -p
git diff --staged
Previous HEAD All Concepts Back To Overview Next Undo + Recovery