semantic-release

Appearance

On this page

Commit messages ​

To automatically increase the version number according to semantic versioning and write changelogs, it is necessary to follow the convention-changelog eslint.

Commit message format ​

Note

The commit messages must have this format when pushing or merging into one of the default branches.

It is not necessary to follow this format inside a feature branch if the commits get squashed. However, in case the merge request does only contain one commit, the commit message must follow the convention.

The eslint convention describes a commit message with the following format:

Tag: Short description [sc-1234]

Longer description here if necessary

The Tag is one of the following:

  • Fix - for a bug fix.
  • Update - either for a backwards-compatible enhancement or for a rule change that adds reported problems.
  • New - implemented a new feature.
  • Breaking - for a backwards-incompatible enhancement or feature.
  • Docs - changes to documentation only.
  • Build - changes to build process only.
  • Upgrade - for a dependency upgrade.
  • Chore - for refactoring, adding tests, etc. (anything that isn't user-facing).

The [sc-1234] is the reference to the shortcut story. You can use the shortcut git helpers for this. The message summary should be a one-sentence description of the change, and it must be 72 characters in length or shorter.

The commit message can be checked git hooks.

Example for commit version changes ​

Let's assume we currently have the version 1.5.2:

Example commit messageVersion changeNext Version number
Breaking: Change the API formatMajor2.0.0
New: Show user pageMinor1.6.0
Update: Avatar to be clickableMinor1.6.0
Fix: Error on API callPatch1.5.3
Upgrade: dependency libraryPatch1.5.3

Only commits with Tag Breaking, Fix, Update, New or Upgrade will trigger a new release. The highest Tag will be used for next version. So when you got 1 minor commit and 3 patch commit, then the minor commit is the highest one.

Git hook to automatically check commit message ​

For client-side validation of the commit message format before committing to development/staging/release, run the following command in the root directory of the repository:

git config core.hooksPath 'node_modules/@lade-software-library/semantic-release/git-hooks'

This has to be done locally for every client.

To check the commit message on server side see Setup service-side git hooks