About Changelog Generator

Generate changelog entries from commits in Keep a Changelog or Conventional formats. Part of the DevTools Surf developer suite. Browse more tools in the Developer Utilities collection.

Use Cases

• Generate release notes from git commit history before tagging a release
• Produce a CHANGELOG.md from conventional commit messages
• Create user-facing release summaries from technical commit descriptions
• Automate changelog creation in CI/CD pipeline before publishing npm packages

Tips

• Paste conventional commit messages (feat:, fix:, chore:, BREAKING CHANGE:) — the generator automatically groups them into Added, Changed, Fixed, and Removed sections
• Set the release version and date in the header fields; the output follows Keep a Changelog format (keepachangelog.com) by default
• Use the 'scope' filter to generate a changelog for a specific package or module in a monorepo

Fun Facts

• The 'Keep a Changelog' format (keepachangelog.com) was created by Olivier Lacan in 2014 and has become the most widely adopted changelog convention in open source. It uses semantic version headers and standard section names.
• Semantic Versioning (semver) was proposed by Tom Preston-Werner (GitHub co-founder) in 2011. The MAJOR.MINOR.PATCH format is now used by over 2 million npm packages — the largest voluntary adoption of a version standard in software history.
• The Conventional Commits specification (2019) was designed specifically to enable automated changelog generation from commit messages. Tools like semantic-release and standard-version parse commit types to determine semver bumps automatically.

FAQ

What is Conventional Commits?

A commit message convention that prefixes messages with types: feat: (new feature), fix: (bug fix), docs:, style:, refactor:, test:, chore:. BREAKING CHANGE in footer triggers a MAJOR version bump. Tools parse these to generate changelogs and semver bumps automatically.

Should I maintain a CHANGELOG.md or just use GitHub releases?

Both are complementary. CHANGELOG.md is checked into the repository — it's versioned, searchable via git log, and accessible offline. GitHub releases add UI discoverability and are linked to tags. Use both for maximum visibility.

How far back in history should the changelog go?

For active projects, document changes since the earliest release you still support. Older unmaintained versions can be marked with a single 'Historical' section. New projects should start from v0.1.0 and document every release.