Staging, commits and reading history

A merge conflict is rare; a messy commit is daily. Interviewers look at your commit history to see whether you work in small, clear steps. This lesson covers the loop you repeat dozens of times a day: check what changed, stage exactly the right parts, commit with a useful message, and read the history back.

The staging loop

git status
git diff
git add src/invoice.py
git add -p src/report.py
git diff --staged
git commit -m "Round invoice totals to two decimals"

git status shows modified, staged and untracked files. git diff shows unstaged changes; git diff --staged shows what will go into the next commit, which is the one to read before you commit. git add -p walks through each change block and asks whether to stage it, so one file with two unrelated fixes can become two commits. Type y to stage a block, n to skip, s to split it smaller.

Commit messages that help

A good message has a subject line of about 50 characters in the imperative mood ("Add", not "Added"), then a blank line, then a short body that explains why, not what. The diff already shows what.

git commit -m "Fix duplicate email on signup retry" -m "The retry handler re-sent the welcome mail because the sent flag was set after the send call, not before. Move the flag update so a crash mid-send is retried but a success is not."

Compare that with "fixed bug" or "changes". Six months later, only the first version tells the next engineer whether it is safe to touch that code.

Reading history

git log --oneline -20
git log --oneline --graph --all
git log -p -- src/invoice.py
git show 3f2a9c1
git blame src/invoice.py

--oneline gives one line per commit, which is the view you use most. Adding a path limits history to that file. git show prints a single commit with its diff. git blame shows which commit last changed each line, so you can read the message that explains it. git commit --amend fixes the last message or adds a forgotten file, but only use it before you push.

Common mistakes and a practice habit

• git add . without reading status, which commits build output, secrets or editor files. Keep a .gitignore and read status every time.
• One huge commit at the end of the day. Reviewers cannot follow it and reverting one part becomes impossible.
• Messages that describe the diff ("change line 40") instead of the reason.
• Amending a commit that is already on the shared branch, which rewrites history others have pulled.

Practice habit. For one week, never run git add .. Stage with -p or by file name, read git diff --staged before each commit, and write a two-line message. Then run git log --oneline and check whether a stranger could follow your day.