Conventional Commits with Semantic Release

Automated Releases with Conventional Commits

One of the primary motivations for Conventional Commits is enabling fully automated release workflows. Tools like semantic-release analyze your commit history to determine the next version number, generate changelogs, and publish releases without any manual intervention.

How It Works

1. Analyze commits since the last release
2. Determine version bump based on commit types:
   • fix: → patch (1.0.0 → 1.0.1)
   • feat: → minor (1.0.0 → 1.1.0)
   • BREAKING CHANGE or ! → major (1.0.0 → 2.0.0)
3. Generate changelog from commit messages
4. Create Git tag and GitHub release
5. Publish package to npm, PyPI, etc.

Setup

npm install -D semantic-release

{
  "release": {
    "branches": ["main"],
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      "@semantic-release/changelog",
      "@semantic-release/npm",
      "@semantic-release/github",
      "@semantic-release/git"
    ]
  }
}

Commit-to-Release Mapping

Commits since last release	Next version
fix: handle null input	Patch: 1.2.3 → 1.2.4
feat: add export feature	Minor: 1.2.3 → 1.3.0
feat!: redesign API	Major: 1.2.3 → 2.0.0
fix: A + feat: B	Minor: 1.2.3 → 1.3.0
fix: A + feat!: B	Major: 1.2.3 → 2.0.0

Generated Changelog

semantic-release groups commits by type:

## [1.3.0] - 2024-03-15

### Features
- **auth:** add OAuth2 login flow (#234)
- **api:** add batch processing endpoint (#256)

### Bug Fixes
- **parser:** handle escaped quotes (#245)
- **ui:** fix layout shift on mobile (#251)

Non-Triggering Types

These commit types do not trigger a release:

• docs: — documentation only
• style: — formatting changes
• refactor: — no behavior change
• test: — test additions
• chore: — maintenance tasks
• ci: — CI configuration
• build: — build system changes

This ensures releases only happen when there are user-facing changes.