Conventional Commit Messages

Types

API relevant changes
- feat Commits, that adds or remove a new feature
- fix Commits, that fixes a bug
refactor Commits, that rewrite/restructure your code, however does not change any API behaviour
- perf Commits are special refactor commits, that improve performance
style Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
test Commits, that add missing tests or correcting existing tests
docs Commits, that affect documentation only
build Commits, that affect build components like build tool, ci pipeline, dependencies, project version, ...
ops Commits, that affect operational components like infrastructure, deployment, backup, recovery, ...
chore Miscellaneous commits e.g. modifying .gitignore

Breaking changes should be indicated by an ! before the : in the subject line e.g. feat(api)!: remove status endpoint

The description contains a concise description of the change.

Is a mandatory part of the format
Use the imperative, present tense: "change" not "changed" nor "changes"
- Think of This commit will... or This commit should...
Don't capitalize the first letter
No dot (.) at the end

The body should include the motivation for the change and contrast this with previous behavior.

feat: add email notifications on new direct messages

feat(shopping cart): add the amazing button

feat!: remove ticket list endpoint

refers to JIRA-1337

BREAKING CHANGES: ticket enpoints no longer supports list all entites.

fix(api): handle empty message in request body

fix(api): fix wrong calculation of request body checksum

fix: add missing parameter to service call

The error occurred because of <reasons>.

perf: decrease memory footprint for determine uniqe visitors by using HyperLogLog

refactor: implement fibonacci number calculation as recursion