Git

Git Strategy

<type>: <description>
_{empty separator line}
<optional body>
_{empty separator line}
<optional footer>

API relevant changes
- feat Commits, that add or remove a new feature
- fix Commits, that fixes a bug
refactor Commits, that rewrite/restructure your code, however, do not change any API behavior
style Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
test Commits, that add missing tests or correct existing tests
docs Commits, that affect documentation only
ci Commits affect build components like build tool, ci pipeline, dependencies, project version, ...
chore Miscellaneous commits e.g. modifying .gitignore

The scope provides additional contextual information.

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.

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

Is an optional part of the format
optionally reference an issue by its id.
Breaking Changes should start with the word BREAKING CHANGES: followed by space or two newlines. The rest of the commit message is then used for this.

feat: add email notifications on new direct messages

feat!: remove ticket list endpoint

refers to JIRA-1337

BREAKING CHANGES: ticket endpoints no longer support listing all entities.

fix: prevent ordering an empty shopping cart

fix: fix the wrong calculation of the request body checksum

fix: add a missing parameter to a service call

The error occurred because of <reasons>.

refactor: Implement Fibonacci number calculation as recursion