DEV Community

Cover image for Commit Standard and Semantic Versioning for any project

Posted on

Commit Standard and Semantic Versioning for any project

One of the biggest problems working with any project is handling commit messages and determinate the next version number of our releases.

We'll add to our project a tool that provides an easy set of rules for creating different commit messages like features, fixes, and breaking changes.

refactor!: drop support for Node 6
docs: correct spelling of CHANGELOG
feat(lang): add polish language
fix: correct minor typos in code

We'll use these commit messages to determine the next version number, generating the release notes, and publishing the packages. As a BONUS, we'll execute this process using Github Actions.

This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification.


Node 10+


Sematic Versioning 2.0.0

Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backward-compatible manner, and
PATCH version when you make backward-compatible bug fixes.


Fill the required commit field at commit time.

Commit fields

Conventional changelog

Generate changelogs and release notes from a project's commit messages and metadata.


To check bad commits.


It helps your team adhering to a commit convention. By supporting npm-installed configurations, it makes sharing of commit conventions easy.

Commitlint - Config conventional

Configuration for Commitlint to enforce conventional commits.

Check ugly commits

Sematic Release

Automates the whole package release workflow, including determining the next version number, generating the release notes, and publishing the package.


Install global dependencies

npm i -g commitizen
npm i -D husky @commitlint/cli @commitlint/config-conventional @semantic-release/git @semantic-release/changelog @semantic-release/commit-analyzer @semantic-release/release-notes-generator @semantic-release/npm


  • Execute commitizen init cz-conventional-changelog -D -E this will add the dependencies of cz-conventional-changelog and update our package with the configuration:
"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"
  • Update package.json to Husky check if the commits follow the conventional standard using commitlint
"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
"commitlint": {
  "extends": [

Now you can check using git cz to commit instead of git commit -m "uggly message"

Sematic versioning with Github Action

  • Create a Personal Access Token with "Repo" permissions
In Github → Settings → Developer settings → Personal access tokens → Generate new token
  • Create a new key GH_TOKEN and the value of the new generated token
In your Repository → Settings → Secrets → New secret
  • Update the package.json with this code
"plugins": [
"release": {
  "prepare": [
      "path": "@semantic-release/git",
      "assets": [
      "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
  • Create a folder in the root of your project .github/workflows with this code.
name: Semantic release

      - master
    runs-on: ubuntu-latest
      - uses: actions/checkout@v2
      - name: Setup Node.js
        uses: actions/setup-node@v1
          node-version: 12
      - name: Install dependencies
        run: npm install
      - name: Semantic release
          GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}
        run: npx semantic-release
  • Now, push your changes to your repo and see in actions.

The command npx semantic-release will analize our commits, generate release notes, update our changelog and generate the release in Github with the information in commits and finally update the version in our package.json.

Feel free to ask any questions you had.


Discussion (0)