Staging & Committing
Moving changes from your working directory into a permanent, named snapshot.
On this page4 sections
With files tracked in a repository, the next skill is turning edits into a real, permanent entry in the history.
Staging: picking what goes in this commit
git add notes.txt # stage one specific file
git add . # stage everything that's changed
Think of the staging area as a loading dock: you place exactly the boxes (files, or even parts of files) you want on this particular truck (commit), and leave the rest for later. That's genuinely useful - it lets you commit "fix the login bug" and "update the README" as two separate, clean commits, even if you happened to edit both files in the same sitting.
Committing: making it permanent
git commit -m "Fix login redirect on expired sessions"
The -m flag supplies the commit message inline. A good commit message is written in the imperative mood - "Fix the bug," not "Fixed the bug" or "Fixes the bug" - as if finishing the sentence "If applied, this commit will...". It's a small convention, but it keeps a project's history reading like a coherent list of actions rather than a diary.
Viewing the history
git log
Every commit shows its unique ID, author, date, and message - a permanent, append-only record of every change anyone has made, in order.
Try it
git add notes.txt
When you're ready, hit Mark complete and move to the next lesson.
Challenge
Stage the file notes.txt, ready to be committed.
Want to experiment first? Try things in the practice terminal (opens in a new tab), then enter the command that solves the task here.
Quiz
Lock in the concepts. Score at least 80% to mark the lesson complete.
Done with this one?
Skipped the challenge? You can mark the lesson complete by hand.