Why I Switched to Conventional Git Commit Messages

For a long time, I didn't really have a consistent pattern for writing Git commit messages.

My commits were usually something like:

update user model
fix login
changes
final changes
fix bug
update
new changes

They worked, but after a while, looking through the Git history became painful.

I couldn't immediately understand what each commit was about, whether it introduced a new feature, fixed a bug, changed the architecture, or was simply a configuration change.

As my projects became larger, especially backend projects with Django and multiple services, I started using a more structured Git commit message convention based on Conventional Commits.

The pattern is simple:

<type>: <description>

I currently use these commit types:

• feat: → a new feature
• fix: → a bug fix
• refactor: → restructuring without changing behavior
• docs: → documentation changes
• test: → adding or updating tests
• chore: → maintenance work such as configuration or dependencies
• perf: → performance improvements
• style: → formatting or linting changes

For example:

feat: add accounts app
feat: add user registration
feat: add email authentication
feat: add team management
feat: add project monitoring
fix: handle duplicate email registration
refactor: improve user authentication flow
chore: update project dependencies
docs: update authentication documentation
test: add accounts app tests

Why I Prefer This Pattern

The biggest benefit is that a Git history becomes readable.

When I look at a project months later, I don't have to open every commit to understand what happened. The commit type already gives me context.

feat:     something new was added
fix:      something was broken and got fixed
refactor: the code changed, but behavior didn't
chore:    project maintenance

It also makes commits easier to search and filter. If I want to see all new features, I can look for feat:. If I'm investigating bugs, I can focus on fix: commits.

More importantly, it forces me to think about what kind of change I'm actually making before committing it.

A commit message like:

update stuff

doesn't tell me much.

But:

refactor: simplify authentication flow

immediately tells me what happened.

I don't think a commit convention needs to be complicated. The goal is not to write perfect commit messages. The goal is to make the history of a project understandable.

For me, this small change made Git history much cleaner and easier to maintain, so this is the pattern I use now for my projects.