Conventional Commits

and
Semantic Release

What Are Conventional Commits?

  • Lightweight convention on top of commit messages

  • Provides clear, machine-readable history

  • Based on Angular commit guidelines

  • Enables automated tools for versioning and changelogs

Why Use Conventional Commits?

  • Automated versioning

  • Automatic changelog generation

  • Clear communication between team members

  • Simplified project history navigation

  • Better code reviews

Basic Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation changes
  • style: Changes that don't affect code meaning (formatting)
  • refactor: Code changes that neither fix bugs nor add features
  • perf: Performance improvements
  • test: Adding or correcting tests
  • build: Changes to build system or dependencies
  • ci: Changes to CI configuration files and scripts

Scope

  • Optional part that provides context
  • Can be component, module, or issue reference
feat(ISE-123): add support for lazy loading
fix(ISE-456): correct handling of string literals
docs(ISE-789): update installation guide

Description

  • Brief summary of the change
  • Follows immediately after the type(scope):
  • Should be in imperative mood (e.g., "add" not "added")
feat(ISE-101): add search functionality
fix(ISE-202): prevent racing of requests

Body

  • Optional detailed description
  • Explains motivation for changes
  • Uses imperative, present tense
  • Includes relevant information about changes
  • Separated from description by blank line
feat(ISE-310): implement user authentication service

This implements a complete authentication service with JWT support.
The service handles token storage, renewal, and validation.
User sessions now persist across browser refreshes.

Addresses security requirements from the latest audit.

Footer

  • Optional metadata
  • Common uses:
    • Breaking changes
    • References to issues
    • Deprecation notices
  • Format: token: value 
feat(ISE-452): add multi-factor authentication

Implements SMS and email verification options.

Closes: ISE-452
Refs: ISE-299, ISE-300
fix(ISE-789): correct date formatting in reports

BREAKING CHANGE: Date format changed from MM/DD/YYYY to YYYY-MM-DD
Co-authored-by: bob@example.com

Breaking Changes

  • Indicated by BREAKING CHANGE: in footer or ! after type/scope
feat!: drop support for Node 12
feat(ISE-304): simplify request API

BREAKING CHANGE: query parameters now passed as object

Best Practices

  • Create as few commits as possible
  • Use types consistently
  • Keep descriptions clear and concise
  • Reference issues when relevant
  • Document breaking changes thoroughly
  • Don't mix unrelated changes

Semantic Release Integration

  • Fully automates the version management and package publishing
  • Uses conventional commits to determine next version number
  • Automatically generates:
    • Version bump (major, minor, patch)
    • Changelog updates
    • Git tags and releases
  • No manual version management needed

How Semantic Release Works

  • Major version (1.0.0 → 2.0.0): Breaking changes (feat!: or BREAKING CHANGE:)
  • Minor version (1.0.0 → 1.1.0): New features (feat:)
  • Patch version (1.0.0 → 1.0.1): Bug fixes (fix:)
  • Other commit types (docs:, style:, etc.) don't trigger releases
  • CI/CD pipeline automatically manages the release process

GitLab Integration With Semantic Release

After pushing to master, "versioning" the job will be available in the pipeline.

 

The job creates a tag, GitLab release, and send release notes on Slack #release_notes_jl

GitLab Integration With Semantic Release

Deployment is initiated automatically after tag creation.

GitLab Releases

Slack Notifications

How to integrate?

Resources

Thank you!

Questions?

Conventional Commits

By Piotr Woszczyk

Made with Slides.com

Conventional Commits

  • 59

More from Piotr Woszczyk