Staaarter Tools

Release Notes Generator

Takes a pasted list of Conventional-Commits-style commit messages or PR titles (one per line) and groups them under Markdown headings, Features, Fixes, Breaking Changes, Documentation, and more, based on each line's commit type prefix, producing a ready-to-publish release notes document. A free online tool from Staaarter, right in your browser.

Runs locallyUpdated 2026-07-26
generatorgitchangelogconventional-commits

Overview

Introduction

Writing release notes by hand from a raw `git log` output usually means manually re-reading and re-sorting dozens of commit messages into categories, a repetitive task that's easy to automate if the commits already follow a consistent prefix convention.

This tool takes a pasted list of commit messages or PR titles and automatically groups them under Markdown headings by their Conventional Commits type, producing a document ready to paste into a release.

What Is Release Notes Generator?

A text-in, Markdown-out grouping tool. You paste a list of commit messages or PR titles (one per line), and it parses each for a Conventional Commits type prefix (feat, fix, docs, refactor, perf, test, chore, build, ci, style) and groups them under a matching heading.

Breaking changes (marked with `!` or containing "BREAKING CHANGE") get their own dedicated heading at the top of the document, ahead of every other category.

How Release Notes Generator Works

Each pasted line has any leading bullet (`- ` or `* `) stripped, then is matched against a `type(scope)?: subject` pattern; a match extracts the type, optional scope, and subject, while a scope (if present) is rendered in bold ahead of the subject in the output.

Matched lines are sorted into a fixed heading order (Breaking Changes first, then Features, Fixes, Performance, Refactoring, Documentation, Build System, CI/CD, Tests, Styling, Chores, and finally Other for anything unmatched), and only headings with at least one entry appear in the output.

When To Use Release Notes Generator

Use it right before cutting a release, paste in the commit messages or merged PR titles since the last release tag, and get a first-draft, categorized release notes document in seconds.

It's also useful for turning a raw `git log --oneline` dump into something a non-technical stakeholder can actually skim by category.

Often used alongside Conventional Commit Message Generator, GitHub Actions Workflow Generator and .gitignore Generator.

Features

Advantages

  • Automatically separates breaking changes into their own prominent section, so they're not buried among ordinary feature commits.
  • Preserves scope information as bold text within each entry, keeping useful context (which subsystem changed) without needing a separate column or table.
  • Never silently drops input, unrecognized lines land in an "Other" section rather than disappearing.

Limitations

  • Only recognizes Conventional Commits-style prefixes; commit messages that don't follow this convention will mostly land in "Other" rather than being categorized correctly.
  • Doesn't deduplicate near-identical entries (like a commit and its later fixup) or fetch commit history itself, you supply the list of messages.

Examples

Grouping a short mixed commit list

Input

feat(auth): add password reset flow
fix: correct pagination off-by-one
feat(api)!: remove legacy /v1 endpoints
chore: bump dependencies

Output

# Release Notes

## Breaking Changes

- **api:** remove legacy /v1 endpoints

## Features

- **auth:** add password reset flow

## Fixes

- correct pagination off-by-one

## Chores

- bump dependencies

The breaking feat commit is pulled into its own top section ahead of the ordinary Features/Fixes/Chores groupings, and each scope renders in bold.

Best Practices & Notes

Best Practices

  • Paste commit messages from a range scoped to exactly the release you're documenting (e.g. `git log v1.2.0..HEAD --oneline`), not your entire project history.
  • Encourage Conventional Commits across your team before relying heavily on this tool, the more consistently commits are typed, the fewer entries land in the catch-all "Other" section.
  • Review and lightly rewrite the generated bullets for a public-facing release, raw commit subjects are often more terse than what end users need to understand a change.

Developer Notes

Type-to-heading mapping is a fixed lookup table (feat→Features, fix→Fixes, etc.) checked against the lower-cased type extracted from each line's regex match; the breaking-change check runs independently of the type match, so even an otherwise well-typed `fix(x)!: ...` commit is correctly pulled into Breaking Changes rather than Fixes. Headings are emitted in a fixed, fixed-order array and simply skipped when empty, rather than being sorted by entry count, so the document's section order stays predictable release over release.

Release Notes Generator Use Cases

  • Drafting release notes for a GitHub Release or CHANGELOG.md entry right before tagging a version
  • Turning a list of merged PR titles since the last release into a categorized summary for stakeholders
  • Quickly checking whether a release includes any breaking changes worth calling out prominently

Common Mistakes

  • Pasting in raw commit hashes along with messages (e.g. from `git log` without `--oneline` or `--format`), which can interfere with the type-prefix pattern match on some lines.
  • Treating the generated draft as final without human review, automated grouping by prefix doesn't catch commits that are mistyped (e.g. `feat:` used for what was actually a fix).

Tips

  • If your commit history doesn't consistently use Conventional Commits, run text through find-and-replace to add a plausible type prefix per line first, the parser is forgiving of anything after the first colon as long as the type/scope portion is present.

References

Frequently Asked Questions