Learning Objectives
By the end of this lesson you will be able to:
- Record staged changes into permanent history with
git commit -m - Write a commit message that is useful to a stranger a year from now
- Apply the imperative-mood convention and the 50-character subject rule
- Recognize the three most common bad-commit habits and fix them
Sealing the Box
You've staged a change. One command writes it into history:
git commit -m "Add negative cases to login smoke checklist"
Git confirms:
[main 4f2a1c9] Add negative cases to login smoke checklist
1 file changed, 12 insertions(+), 2 deletions(-)
4f2a1c9 is the beginning of the commit's unique hash — its permanent address. That string is what you paste into a bug report when you say "reproduced on this build". The staging area is now empty, and git status reports a clean working tree.
The -m flag supplies the message inline. Leave it off and Git opens a text editor instead — useful for longer messages, and a well-known trap if that editor turns out to be Vim and you don't know that :wq gets you out.
Why the Message Is the Point
A repository's history is documentation that writes itself — but only if you write the messages.
Consider a real history from a project where nobody cared:
* 8a3f2c1 fix
* 91bd4e7 update
* c7f0a12 changes
* 4e9d331 fix again
* 0b2c8a5 asdf
Now consider one where somebody did:
* 8a3f2c1 Add boundary cases for 3-digit CVV validation
* 91bd4e7 Update staging DB connection string after migration
* c7f0a12 Remove flaky wait from checkout regression suite
* 4e9d331 Document reproduction steps for BUG-441
* 0b2c8a5 Add smoke checklist for the new payments flow
Both took the same amount of typing. Only one lets you answer "when did the staging config change, and why?" without interrogating a colleague. As a tester you will read histories like this constantly — and eventually you'll be the one who wrote them.
The Rules That Matter
1. Use the imperative mood. Write Add, Fix, Remove, Update — not Added, Fixes, or Adding. The convention is that a commit message completes the sentence "If applied, this commit will ___". It reads oddly for about a week, then becomes invisible, and it matches what Git itself generates for merges and reverts.
2. Keep the subject line under ~50 characters. Tools truncate it: git log --oneline, GitHub's commit list, IDE blame views. A subject that gets cut off mid-word helps nobody.
3. Say what and why, never how. The diff already shows how. "Fix login test" is weak; "Fix login test failing after 2FA rollout" tells the reader something the code can't.
4. One commit, one logical change. This is what the staging area is for. If your message needs the word "and", you probably wanted two commits.
5. Reference the ticket. If your team uses Jira, Linear, or GitHub Issues, put the ID in the message: Add regression cases for BUG-441. Most tools link it automatically, turning your history into a navigable trail between code and context.
Longer messages
When a change genuinely needs explaining, drop the -m and write a body:
Remove hardcoded wait from checkout suite
The 5-second sleep masked a real race condition in the
cart total calculation. Replaced with an explicit wait
on the total element so the underlying bug surfaces.
Refs: BUG-512
Subject line, blank line, body. The blank line is not optional — Git uses it to separate the two.
Three Habits to Break
Committing at the end of the day, once, for everything. The result is a giant untraceable blob. Commit each finished thought instead.
"WIP" as a permanent message. Fine on a scratch branch you'll clean up; corrosive on shared history.
Describing the file instead of the change. "checklist.md" tells the reader what they can already see in the diff. Tell them what you did to it and why.
Pro Tip: Made a typo in the message you just wrote and haven't pushed yet?
git commit --amend -m "Corrected message"rewrites it. Only ever do this to a commit that hasn't left your machine — amending a pushed commit changes its hash and creates confusion for everyone who already has it.
Key Takeaways
git commit -m "message"writes the staged change into permanent history with a unique hash- The commit hash is the precise identifier to cite in bug reports and release notes
- Use the imperative mood, keep the subject under ~50 characters, and explain what and why
- One commit should contain one logical change; "and" in a message is a sign to split it
git commit --amendfixes the most recent message, but only before the commit has been pushed