Hermes

# Versioning

# Semantic Versioning

Solarix uses traditional semantic versioning to indicate the compatibility of each committed changed.

# Commit Message Syntax

Solarix uses the Conventional Commits specification, which defines how a proper commit message should be formatted.

A commit message consists of a title, body, and footer. The title is the only required line and it MUST have a type and subject field. It also usually has a scope, which defines which aspect of the project the commit applies to:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The body can contain any necessary text to support the commit. The footer is typically where relationships are mentioned, such as closed issue, affected merge request, impacted branch, etc.

# Breaking Changes

Any commit that introduces a breaking change should be formatted in either one of two ways:

  • An explicit ! character between the type(subject) and colon separator within the title: fix(ui)!: changes ALL THE THINGS
  • The text BREAKING CHANGE: and two new lines should prepend the commit message: BREAKING CHANGE:\n\nfix(ui): changes ALL THE THINGS

# Examples

# Feature

feat(dashboard): add 'user' model

Everyone loves a good dashboard.  Now users can enjoy it.

Closes #15.
  • Increments MINOR version due to feat type.
  • Adds the title to the generated changelog under Features header.
  • Links to issue #15.

# Fix

fix(dashboard): remove unintended access for Satan

Sure, everyone loves a good dashboard, but we can't let just ANYONE use it...

Closes #666.
  • Increments PATCH version due to fix type.
  • Adds the title to the generated changelog under Bug Fixes header.
  • Links to issue #666.

# Breaking Change

fix(ui)!: changes ALL THE THINGS
  • Increments MAJOR version due to ! breaking change indicator.
  • Adds the title to the generated changelog.

# Commit Message Linting

The Commitlint package is enabled to assist in generating properly formatted commit messages.

See the .commitlintrc.js file for the full ruleset.

TIP

JetBrains users may want to check out this plugin.

# Git Hooks

The Husky package is used to perform Git hook-related tasks, the most important of which is linting. When attempting a commit a git hook performs linting via commitlint as mentioned above, checking the validity of your commit message. Any errors are indicated in the console and the commit is cancelled.

See the .huskyrc.js example file for the configuration.

# Commit Message Generation

For step-by-step assistance creating a valid commit message you may use the included Commitzen package. Instead of git commit or committing via your IDE, run the yarn commit command. This will open the Commitizen CLI UI which will walk you through a series of questions to build up the full, valid commit message.

TIP

Power-users will probably find it faster to manually write commit messages, but Commitizen is a handy way to get used to the necessary syntax.

← Contributing →