Conventional Commits
6/2/2025
Intro
If you’ve ever scrolled through a teammate’s git log and thought, “Who pushed this cryptic Update stuff commit at 3 a.m.?”—grab a coffee, this one’s for you. Conventional Commits give your history the order it deserves, and Google’s Release Please turns that tidy history into autopilot releases. Let’s break down why this combo is pure productivity fuel.
TL;DR (because we all love quick wins)
Conventional Commits add predictable “metadata” to every commit (feat:, fix:, docs:…), which machines can parse. That structure lets Release Please read your history, decide whether the next version is 1.2.4 or 2.0.0, open a PR that bumps the version, and ship a ready‑made changelog. Less yak‑shaving, more code‑shipping.
From Copilot Suggestions to a Release Pipeline
I first stumbled on Conventional Commits when GitHub Copilot auto‑suggested a tidy line like fix(api): resolve nil pointer panic. The pattern felt too intentional to be random, so I dug in and discovered there’s an entire spec behind it. That rabbit hole paid off: when it came time to add automated releases to a Go side‑project, I tested a handful of GitHub bots that honor the convention and settled on Release Please—it’s Google‑maintained, language‑agnostic, and plays nicely with Go modules. To close the loop, I wired up Commitlint so every commit sticks to the spec—and later brought the same tooling into one of my open‑source projects Talia to make releases effortless.
Why Bother Standardising Commits?
1. Instant Context for Humans
A glance at git log --oneline tells the story: feature vs. bugfix vs. docs tweak. No more playing detective.
2. Automation Super-Powers
Tools like semantic-release or Release Please mine commit messages to pick the next SemVer and draft changelogs.
3. Fewer “Oops, Wrong Version” Moments
Using feat!: or adding a BREAKING CHANGE: footer flags Release Please to bump the major version—so the robot catches what sleepy devs might miss.
Side note: it’s like giving your CI a cheat sheet so it stops waking you up at 2 a.m. asking, “Patch, minor, or major, ?”
Conventional Commits: The 30-Second Primer
<type>(optional-scope): <short description>
BODY (optional, wrapped at 72 chars)
BREAKING CHANGE: <explanation>Common types:
| type | SemVer bump | Why it matters |
|---|---|---|
fix | patch | A bug got squashed |
feat | minor | A shiny new capability |
feat! / any! | major | Something will break |
If you’ve used Angular’s commit guidelines, this will feel familiar—Conventional Commits evolved from there.
Meet Release Please: Your Robot Release Manager
-
Scans commit history for Conventional Commit tags.
-
Calculates the next version based on SemVer rules.
-
Drafts a PR that bumps version files & writes
CHANGELOG.md. -
On merge, tags the repo and creates a GitHub release.
Why It Matters
-
Fire-and-forget: merging the PR is literally the “ship it” button.
-
Handles multi-package monorepos (JS, Go, Rust, even elixir).
-
Plays nicely with your language-specific publish steps—npm, PyPI, crates-io, whatever.
Setting Up the Safety Nets
| Tool | Purpose | Quick Link |
|---|---|---|
| Commitlint | Blocks bad commit messages in CI or pre-commit hooks | |
| Commitizen | Interactive CLI that writes the commit message for you | |
| Release Please GitHub Action | Adds the robo-release workflow to your CI |
Commitlint enforces the spec at commit time, while Commitizen prevents you from even typing the wrong thing.
Take-away
Conventional Commits create a machine-readable commit history; Release Please converts that history into versions, tags, and change logs while you focus on code. The result is a tidy Git log, disciplined SemVer, and fewer late-night release scrambles. Adopt the spec, wire up the tooling, and let your CI do the boring stuff—your future self will thank you.
Happy committing—and may your git log never need archaeology tools again!