Writing Better Git Commit Messages — What I Learned from Experience

Is writing a good commit message really that important?

After working on projects for quite some time, I’ve realized that a clear, to-the-point commit message makes teamwork a whole lot easier — and it helps me too when reviewing or debugging code later!

Lately, I’ve been more intentional about how I write my commits, and honestly, the entire process has become smoother and more enjoyable.

Why do good commit messages matter?

• Easier team collaboration: No more guessing games about who changed what.
• Faster debugging: Tools like git blame and git bisect are only useful when the messages give actual clues.
• Quicker code reviews: A good message helps the reviewer understand what to focus on instantly.

The format I follow (and it really works!)

I stick to a simple, consistent format:

<type>(<scope>): <short, clear summary>

• type: feat, fix, docs, style, refactor, test
• scope: the part of the project (like auth, ui)
• summary: under 50 characters, written in the imperative mood (e.g., “Add”, “Fix”, “Refactor”)

If needed, I also add:

• Body: What I did and why I did it (not just what)
• Footer: Issue numbers (e.g., Closes #123) or notes about breaking changes

A few real examples I use:

• feat(api): add user-profile endpoint
• fix(ui): prevent navbar overflow on mobile
• docs(readme): update installation instructions
• refactor(auth): extract token logic into service
• test(payment): add unit tests for Stripe webhook handler

What I avoid now:

• ❌ Vague messages like "stuff" or "bugfix"
• ❌ Non-descriptive ones like "updated files"

Since I started following this approach, things have become more efficient — both for me and my team. Less confusion, fewer meetings, and faster progress. 😄

What’s your approach to writing commit messages?
Would love to hear your style or tips — feel free to share in the comments!