Git Commit Message Best Practices: The 7 Rules
A git commit message explains what changed and, more importantly, why. Good messages make git log, git blame, and code review dramatically faster.
The 7 Rules
- Separate subject from body with a blank line. Lets
git log --onelineshow just subjects. - Limit subject to 50 characters. GitHub and most UIs truncate at 72; 50 gives breathing room.
- Capitalize the subject line. Fix timeout bug, not fix timeout bug.
- No period at the end. It is a title, not a sentence.
- Use imperative mood. Write Add feature, not Added or Adding.
- Wrap body at 72 characters. Keeps messages readable in terminals.
- Body explains what and why, not how. The code shows how; the message explains the reason.
Before: fixed stuff
After:
Fix payment gateway timeout on slow connections
Default 30s HTTP timeout too short for high-latency mobile.
Increase to 90s per gateway docs. Fixes #847.
Conventional Commits
Structured prefix format: type(scope): description. Types: feat, fix, docs, refactor, test, chore. Enables automated changelogs and semantic versioning.
feat(auth): add OAuth2 login via Googlefix(payments): handle timeout on slow connectionsdocs(api): add rate limit section to README
Tip:
git log --oneline --graph on a well-maintained project vs a poorly-maintained one shows the difference immediately. Good commit history is a form of documentation.