What is it?
A commit message explains what changed and why. Good commit history is documentation — it tells how the codebase evolved and makes debugging and review easier.
Why does it matter?
Recruiters and senior engineers read commit histories to assess code quality. Vague commits signal inexperience. Clean commit messages are marks of a professional developer.
Write meaningful commit messages, use conventional commits, and amend commits.
Real-World Use Cases
- 🔍 Debugging with blame - Good messages explain WHY code exists — git blame shows which commit introduced any line.
- 🔄 Safe revert - Atomic commits make it safe to revert exactly one feature without affecting others.
- 📋 Automated changelogs - Conventional commits (feat:, fix:) enable auto-generated changelogs.
- 👥 Code review - Meaningful commits make Pull Request review easier to understand.
Good vs Bad Messages
# BAD:
git commit -m "fix"
git commit -m "stuff"
# GOOD: imperative mood, under 72 chars, explains WHY
git commit -m "Fix login redirect loop on expired session"
git commit -m "Add rate limiting to /api/login (prevent brute force)"Conventional Commits
feat(auth): add Google OAuth login
fix(cart): prevent negative total when qty is zero
docs(readme): add Windows installation instructions
refactor(api): extract payment processing into service class
test(user): add unit tests for email validation
feat(api)!: change response format # ! = BREAKING CHANGEAmend and Clean Up
git commit --amend -m "Better message" # fix last commit message
git add forgotten.php && git commit --amend --no-edit # add missed file
git rebase -i HEAD~5 # interactive: squash, reword, fixup WIP commitsQ: How many changes should go in one commit?
One logical change per commit. If you can describe it with 'and', it should be two commits. Atomic commits that are complete and working on their own make reverting and cherry-picking much easier.
Comments (0)
No comments yet. Be the first!
Leave a Comment