Conventinal Commit Messages

See how a minor change to your commit message style can make a difference. Examples

Have a look at CLI util conventionalcommits to ensure this conventions and generate changelogs

Have a look to the conventional commits Playground playground

Commit Formats

Default

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

Merge

Merge branch '<branch name>'

^{Follows default git merge message}

Revert

Revert "<commit headline>"
empty separator line
This reverts commit <commit hash>.
<optinal reason>

^{Follows default git revert message}

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 refactor commit, that improves 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
• doc 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 Commits, that are not affecting production code changes ...

Scopes

The scope provides additional contextual information.

• Is an optional part of the format
• Allowed Scopes depends on the specific project
• Don't use issue identifiers as scopes

Subject

The subject contains a succinct description of the change.

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

Body

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

• Is an optional part of the format
• Use the imperative, present tense: "change" not "changed" nor "changes"
• This is the place to mention issue identifiers and their relations

Footer

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.

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 version 1.0.0
  

• build: update dependencies
  

• refactor: implement calculation method as recursion
  

• style: remove empty line
  

• revert: refactor: implement calculation method as recursion
  
  This reverts commit 221d3ec6ffeead67cee8c730c4a15cf8dc84897a.