The daily workflow — status, diff, add, commit, log
Five commands cover the overwhelming majority of everyday Git usage — not memorized in isolation, but as one continuous loop you repeat dozens of times a day without thinking about it.
4 min read
git status: what actually changed, right now
$ git status
On branch main
Changes not staged for commit:
modified: app.py
Untracked files:
new_feature.py
git status is the command to run constantly, before doing almost anything else — it shows which tracked files have been modified, which new files exist that Git doesn't know about yet (untracked), and which changes are already staged for the next commit. Running it reflexively, before and after nearly every other Git command, is what keeps "what state is my repository actually in" from ever becoming a mystery.
git diff: exactly what changed, line by line
$ git diff
- def greet(name):
- return "Hello " + name
+ def greet(name):
+ return f"Hello {name}"git diff shows the actual line-by-line changes in the working directory that haven't been staged yet — lines removed shown with -, lines added shown with +. This is the concrete way to review exactly what you're about to stage, before staging it — genuinely worth running before every git add, especially on a file with more changes than you fully remember making.
git add: choosing what goes into the next commit
git add app.py # stage one specific file
git add app.py utils.py # stage several specific files
git add . # stage everything changed in and below the current directory
This is the previous lesson's staging step, in practice — git add moves specific changes from the working directory into the staging area. git add . is convenient but worth using deliberately, not reflexively: it stages everything changed, including files you might not have meant to include yet — git status right before running it is what confirms exactly what's about to be staged.
git commit: saving the staged snapshot, with a message
git commit -m "Fix greeting to use an f-string"
-m "message" provides the commit message inline; without -m, Git opens a text editor for a longer message. The message matters more than it might seem — it's what makes git log (below) actually useful months later, when "what was this commit for" has to be answered by reading the message, not by re-reading the entire diff.
git log: the history itself
$ git log --oneline
a3f8e21 Fix greeting to use an f-string
9c2d104 Add new_feature.py
7b1a880 Initial commit
git log shows the commit history — by default, each commit's full hash, author, date, and message; --oneline (a genuinely useful flag) condenses each commit to one line: a short hash and the message. This is the previous lesson's "chain of linked commits" made visible and browsable — every commit here is a real, restorable snapshot of the project at that exact point.
The loop, put together
This loop — edit, check status, review the diff, stage, commit — repeats dozens of times over the course of ordinary work, and it's worth internalizing as one continuous habit rather than five separate commands to remember independently. status and diff cost nothing and catch mistakes (staging a debug print statement, forgetting a file) before they become permanent commits; skipping them to save a few seconds is a common way small mistakes end up baked into history.
A practical habit: commit small, commit often
Bad: one commit at the end of the day, containing 15 unrelated changes
Good: one commit per logical change — "fix login bug," "add email validation," "update README"
A commit is meant to be one coherent, describable change — not an end-of-day dump of everything touched. Small, focused commits make git log genuinely useful (each entry describes one real thing), make it possible to undo just one specific change later without also undoing unrelated work, and make reviewing a change (your own, or a teammate's) far more manageable than reviewing one enormous commit that mixes several unrelated things together.
Further reading
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why is git status worth running before and after nearly every other Git command?
2. What does git diff show that git status doesn't?
3. Why is git add . worth using deliberately, checking git status first, rather than reflexively?
4. Why is 'commit small, commit often' generally better than one large commit at the end of the day?