Choosing what goes into the next commit
Staging is the step where you select which working changes belong in your next commit. In Git, the place those selected changes sit is called the staging area, or the index.
Saving a file does not put the change into a commit. On the command line you use git add; in GitHub Desktop or SourceTree you tick the files you want.
Why there is a selection step at all
Over a working day you accumulate changes with different purposes. If you want a heading fix and a new feature in separate commits, staging is how you pick out just one of them.
That step is what lets you size a commit so its purpose can be described. Committing everything at once every time makes the history much harder to read later.
Save, stage, commit
- Save: write your edits to the file
- Stage: select the changes for the next commit
- Commit: record the selected changes in Git’s history
Review the diff before committing
The staged set is also your last checkpoint. Look at the diff for debug output, stray reformatting, or an API key that slipped in.
git add . selects a lot at once and can pull in files you did not mean to include. Until you are comfortable, going file by file is safer.
Unstaging does not normally discard your edits — it returns the change to “not in the next commit”. That is different from reverting, so read the labels in your client carefully: Unstage and Discard Changes do very different things.
If you edit a file again after staging it, the staged version and the newer unstaged version both exist. Checking the diff once more just before committing avoids surprises.