[fn1]

Interesting, after years of software-development I arrived at almost the same pattern:

* [feature] -> a new feature, can be incomplete, but should be a contained unit of work that's usable to the enduser in some way.

* [code] -> everything that improves the code, could be refactoring, library-updates or preparations for a feature

* [bugfix] -> minimal commit only for fixing a bug, should (almost) always include a test to reproduce the bug.

Sometimes I also use:

* [build] -> for build-improvements

* [performance] -> for performance-improvements

[beanaroo]

After working on a number of projects that tried to apply conventional commits properly, I found something like this to be more effective and sustainable.

Specifically, I'm quite fond of https://gitmoji.dev

- Commit messages are shorter, even with ticket IDs.

- Commit log is easy to read

- Less prone to typos (chroe vs chore)

- Easy to enforce with push rules

- Easy to generate changelogs/release notes

- Easy to measure (metrics)

- Helpful IDE integrations

- It's a bit more fun than conventional commits

See https://github.com/tiangolo/fastapi for an example