How to Make Git Commits That Make Sense
Good commit messages are like leaving notes for your future self. Learn how to write git commit messages that actually help you understand your project's history.
What a Commit Message Actually Is
When you save a file on your computer, it just gets saved. But when you make a commit in Git, you're creating a snapshot of your project with a label attached to it. That label — the commit message — is your note to yourself (and your team) about what changed and why.
Think of Git like a photo album for your project. Each commit is a photo. A bad commit message is like labeling a photo "photo 47" — technically accurate, but completely useless when you look back at it six months later. A good commit message is like writing "Team dinner at Nonna's, Alex's birthday, May 2024" — instantly meaningful.
Commit messages are read by humans: you, six months from now, trying to figure out why a feature broke. Your teammate debugging something at 2am. A new developer joining the project. The code itself doesn't explain the reasoning — the message does.
Your Future Self Will Thank You
Have you ever looked back at an old project and had no idea why you changed something? That's what bad commit messages cause. When you're deep in a bug hunt, the commit history is your map. Every unclear message is a dead end on that map.
Good commit messages also make code reviews faster and smoother. When a teammate can read "Added form validation to the contact page because users were submitting empty forms" instead of "fixed stuff", they know exactly what to look for and why the change exists.
On big projects with many contributors, commit messages are how everyone stays aligned. They're not just notes — they're a shared record of decisions made over the life of a project.
💡 Key Insight
A commit message is not about what changed — any developer can read the code for that. A commit message is about why it changed. That's the part you can't get from the code itself.
The Anatomy of a Good Commit Message
Here's a simple formula that works for most commits:
First line (short summary): What changed, in 50 characters or less. Imagine finishing this sentence: "This commit will..."
Blank line.
Body (optional): Why this change was made. What problem does it solve? What did you try that didn't work? Is there a related issue or ticket number?
Be Specific
"Fixed bug" is useless. "Fixed login crash when password field is empty on iOS" is perfect.
Lead with the Verb
Start with "Add...", "Fix...", "Remove...", "Update...". It makes messages scan-able instantly.
Answer "Why?"
The code shows what. The message explains why. That's the part you'd forget in a week.
Bad vs. Good Commit Messages
Let's look at the same change — adding a new feature to a website — with different commit messages:
Bad Examples
- ❌ "fix"
- ❌ "updates"
- ❌ "WIP"
- ❌ "asdfasdf"
- ❌ "changes"
Good Examples
- ✅ "Add dark mode toggle to settings page"
- ✅ "Fix header overlap on mobile viewports below 375px"
- ✅ "Remove deprecated jQuery plugin — replaced with vanilla JS equivalent"
- ✅ "Update pricing page copy to reflect 2026 plan changes"
- ✅ "Add email validation to signup form to prevent typo spam"
Here's how you'd write a real commit with a good message:
git add . git commit -m "Add password strength meter to signup form Users were signing up with weak passwords like '123456'. Added a live strength indicator that checks length, numbers, and special characters before allowing submission. Closes #142"
The first line is short and specific. The blank line separates it from the explanation. The body explains the reason for the change and links to the relevant ticket. That's a message worth reading.
Knowledge Check
Test what you learned with this quick quiz.