How can I automate my changelog from merged PRs?

To automate your changelog from merged PRs, give every pull request a consistent label or a Conventional Commits title, then let a tool turn merged PRs into changelog entries: GitHub's auto-generated release notes or Release Drafter group PR titles by label, release-please and git-cliff build a CHANGELOG.md from commit messages, and Engammo, a GitHub App, writes an AI release note for each merged PR and publishes it to a changelog page. The steps below walk through the setup, from labels to publishing.

The right tool depends on who reads your changelog. Developers are well served by a list of PR titles grouped into sections. Customers, product managers, and support need plain language, which is where AI-written notes help.

The options at a glance

Step 1: Decide who the changelog is for

Write down the audience before you pick a tool. A developer changelog lives in CHANGELOG.md or GitHub Releases and lists changes by category. A product changelog lives on a public page or inside your app and explains what changed for users. Many teams need both, and it is fine to automate them with different tools.

Step 2: Make every PR classifiable

Every changelog tool needs to know whether a change is a feature, a fix, or something to leave out. There are two common conventions:

• PR labels such as feature, bug, breaking-change, docs, and dependencies. GitHub auto-generated notes, Release Drafter, and Engammo all read labels.
• Conventional Commits such as feat: add CSV export or fix: handle empty project names. release-please, semantic-release, and git-cliff read commit messages. If you squash-merge, the PR title usually becomes the commit subject, so enforcing the convention on PR titles is often enough.

Pick one and make it hard to forget: add the labels to your PR template checklist, or use a labeler or PR title check in CI. Clear PR titles and descriptions matter too, because they end up in the changelog.

Step 3: Pick the tool that generates entries

GitHub auto-generated release notes

The zero-install option. When you draft a release on GitHub, generate the notes and GitHub lists the PRs merged since the previous release, plus new contributors. To group PRs by label, add .github/release.yml:

changelog:
  exclude:
    labels:
      - ignore-for-release
    authors:
      - dependabot
  categories:
    - title: Breaking Changes
      labels:
        - breaking-change
    - title: New Features
      labels:
        - feature
        - enhancement
    - title: Bug Fixes
      labels:
        - bug
    - title: Other Changes
      labels:
        - "*"

This is still a manual step per release, but the writing is done for you.

Release Drafter

Release Drafter is a GitHub Action that updates a draft release after every merge, so the notes are always ready. You configure categories, an entry template, and version resolution from labels in a YAML file. If you want less YAML, see our Release Drafter alternatives.

release-please (or semantic-release)

release-please reads Conventional Commits on your main branch and keeps a release PR open with the next version and the updated CHANGELOG.md. Merging that PR tags the release. semantic-release is the fully automatic variant: it releases on every qualifying merge. Both are best for packages and libraries where versioning matters as much as the changelog.

git-cliff

git-cliff is a CLI that renders your commit history into a changelog through a template you control. Run it in CI after each merge or before each release and commit the output.

Engammo

Engammo skips the configuration. Install the GitHub App, pick repositories, and every merged PR becomes a release note within seconds:

1. A pull request merges on GitHub and GitHub sends a webhook to Engammo.
2. Engammo reads the PR title, description, labels, and a trimmed summary of the changed files.
3. AI writes a short title, a one-sentence description, and a few plain-language bullets.
4. The note is tagged from your labels: bug, fix, and bugfix become fixes; feature, enhancement, and feat become features; breaking and breaking-change become breaking changes; security, refactor, docs, infra, chore, and dependencies are recognized too.
5. The note is published to your changelog page, widget, RSS feed, and public JSON endpoints.

When you tag a version, Engammo can also compile every change between two Git tags into one versioned release note. No commit convention is required, and your existing Release Drafter labels keep working.

Step 4: Publish where readers already are

A changelog nobody sees is not much better than none. Developer changelogs belong in GitHub Releases and CHANGELOG.md. Product changelogs need a public page, an in-app widget, or a feed. Engammo gives you a hosted changelog page, a one-script-tag widget, an RSS feed, and JSON endpoints you can pull into your docs or app.

Step 5: Keep a human in the loop

Automation removes the blank page, not judgment. Skim new entries once a week: fix a misleading title, hide internal changes, and add context to anything customers will notice. With Engammo every note can be edited, regenerated, or hidden from public pages. With the open source tools, edit the draft release or the generated release PR before you publish.

A setup that works for most teams

• Labels on every PR, enforced by your PR template.
• release-please or GitHub auto-generated notes for versioning and the developer changelog.
• Engammo for the customer-facing changelog, written in plain language from the same PRs.

Engammo's Free plan covers 1 repository, 15 release notes per month, and 10 AI summaries per month; Pro is $19/month for up to 5 repositories and unlimited notes. It works with repositories on GitHub.com, including GitHub Enterprise Cloud. For more on the AI side, read our guide to AI release notes generators for GitHub, or the earlier walkthrough on automating release notes from GitHub commits.