Using "conventional commits" formatting rules

[the-hampel]

Let's use in future these common rules to tag commit messages and make them more human readable:
www.conventionalcommits.org

Short summary from qoomon/conventional_commit_messages.md:

Commit Format:

<type>(<optional scope>): <subject>
empty separator line
<optional body>
empty separator line
<optional footer>

Types

• API relevant changes
  • feat Commits, that adds a new feature
  • fix Commits, that fixes a bug
• refactor Commits, that rewrite/restructure your code, however does not change any 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

Scopes (optional)

The scope provides additional contextual information.

Subject

The subject contains a succinct description of the change.

Body

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

Footer (optional)

The footer should contain any information about Breaking Changes and is also the place to reference Issues that this commit refers to.

Examples

• 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: add missing parameter to service call
  
  The error occurred because of <reasons>.
  

• build(release): bump version to 1.0.0
  

• build: update dependencies
  

• refactor: implement calculation method as recursion
  

• style: remove empty line