Why I Switched to Conventional Commits (and Why You Should Too)

Hello Buddy,

This is Ankit, a Python developer currently floating in the AWS cloud.

When I started writing code, I was always stuck when it came to committing. I had no idea what to write in a commit message, which often resulted in me not committing any code for a long time. Eventually, when it was time to push, I would end up with so many lines and files changed all dumped into one ugly commit.

I kept doing this for a long time.

Then I realized my mistake and started committing code based on a feature or fix, This small change helped me understand my code better and work in a more structured way.

However, I still wasn't following any pattern when writing commit messages. This made my project’s commit history look weird and inconsistent.

While exploring some open-source code, I noticed certain patterns in commit messages. That's when I discovered Conventional Commits as one of the best and most effective ways of writing commit messages.

Now, I use it every day.

My old commit style (bad examples):

update
fix bug
done some changes

My new commit style (Conventional Commits examples):

feat(auth): add support for Google login
fix(api): handle empty payload in POST requests
refactor(db): improve query performance for user search

Why Conventional Commits Helped Me

• Clear history - I can look at git log and instantly understand what each commit does.
• Better collaboration - Team members know exactly what changed and why.
• Automation - Tools can automatically generate changelogs or trigger CI/CD steps based on commit types.
• Discipline - It forces me to break work into smaller, meaningful chunks.

Final Thoughts

If you often find yourself with one massive commit and a vague message, try adopting Conventional Commits.

Start small: pick one convention (feat, fix, docs, etc.) and stick with it. Over time, you’ll see your commit history become cleaner, more meaningful, and far easier to work with for both you and your team.