# How to generate a changelog from GitHub pull requests Three reliable ways to turn merged GitHub pull requests into a changelog — GitHub's built-in release notes, a GitHub Action, or an AI changelog tool — plus how to make your PRs changelog-ready. You can generate a changelog from GitHub pull requests in three main ways. GitHub's built-in "Generate release notes" button drafts notes from merged PRs between two tags. A GitHub Action such as Release Drafter compiles a draft release automatically as PRs merge, grouping entries by label. A changelog tool reads your merged PRs directly and drafts the release with AI. The first two produce engineer-facing notes anchored to your repo; to turn the same PRs into a customer-facing changelog on a hosted page, widget, and email, a tool like Herald reads your merged PRs, drafts plain-English entries with AI, and can publish back to GitHub Releases. Published: June 2026 Last reviewed: 2026-06-15 Author: Herald Team Category: GitHub Integration Read time: 8 min read Tags: GitHub, Pull Requests, Changelog automation, GitHub Actions ## The short answer Your merged pull requests are already a structured record of everything you shipped: a title, a description, labels, and the diff behind them. Generating a [changelog](/glossary/changelog/) from them is mostly a question of which tool reads that record and who the output is for. There are three reliable approaches, from least to most automated: 1. **GitHub's built-in "Generate release notes"** — manual, per release, free, lives on github.com. 2. **A GitHub Action** (such as Release Drafter) — drafts a release automatically as PRs merge, grouped by label. 3. **A changelog tool that reads your PRs** — pulls merged PRs directly and drafts entries with AI, for a customer-facing changelog. The first two are built for an engineering audience. The third is what you reach for when the people reading the changelog are your _users_, not your contributors. We'll walk through all three, then cover the PR hygiene that makes every one of them produce better output. ## Option 1: GitHub's built-in release notes GitHub can draft release notes from merged PRs without any extra tooling. It's the fastest way to get something, and for many library and SDK projects it's enough. To use it: 1. Tag a release (or be ready to create a new tag). 2. In your repo, open **Releases** → **Draft a new release**. 3. Choose the tag for this release and the previous tag to define the range. 4. Click **Generate release notes**. GitHub lists every merged PR in that range, plus new contributors and a link to the full diff. You can group and filter what shows up by adding a `.github/release.yml` file that maps labels to categories: ```yaml changelog: categories: - title: Features labels: [feature, enhancement] - title: Bug Fixes labels: [bug, fix] - title: Other Changes labels: ['*'] ``` With that in place, the generated notes arrive already sorted into Features, Bug Fixes, and Other Changes based on each PR's labels. **Where it shines:** zero setup, free, anchored to the exact tag you shipped. **Where it stops:** the output is a list of PR titles written by and for engineers, and it lives on your GitHub Releases page — a surface most of your customers will never visit. (More on that trade-off in [Herald vs GitHub Releases](/compare/github-releases/).) ## Option 2: Automate it with a GitHub Action If you don't want to click "Generate release notes" by hand every release, a GitHub Action can keep a draft release continuously up to date. The most common pattern is to run a changelog action on every merge to your main branch: it reads the PRs merged since the last release and rewrites a draft release, grouping entries by label. A widely used option is **Release Drafter**, which maintains a single draft release and updates it each time a PR lands, so a near-finished changelog is always waiting when you're ready to publish. You configure the categories and version-bumping rules in a config file, then a short workflow runs the action on merge. (Treat any specific workflow YAML as something to copy from the action's current docs rather than from memory — Actions change their inputs between major versions.) If your team follows [Conventional Commits](/glossary/conventional-commits/), the [conventional-changelog](/glossary/conventional-changelog/) ecosystem (and tools like semantic-release) can generate the changelog and bump the version automatically from commit prefixes like `feat:` and `fix:`. This works best when you squash-merge PRs so each PR becomes one well-formed commit. **Where it shines:** no manual step, consistent formatting, version bumps handled for you. **Where it stops:** same audience problem as Option 1 — the result is engineer-facing release notes in your repo, not something written for the person paying for your product. ## Option 3: An AI changelog tool that reads your PRs The first two options answer "how do I list what changed?" A changelog tool answers a different question: "how do I tell my _users_ what changed, in language they'll actually read?" [Herald](/) reads your merged GitHub PRs and drafts the release with AI. You connect a repo, and when you're ready to cut a release you pick one of three source modes: - **Merged PRs since a date** — everything that landed in a time range. - **Compare branches** — the diff between two branches. - **Compare releases or tags** — the diff between two versions. Herald's AI reads the PR titles, descriptions, and labels and drafts a clean, grouped, human-readable entry. You review it in the editor — reorder items, drop internal-only changes, rewrite anything that came out too technical — and publish. The same release can publish to a hosted changelog page, an embeddable in-app widget, and email subscribers in one action. On Team plans it can also publish back to GitHub Releases, so your engineer-facing and customer-facing notes stay in sync from one source of truth. (For when to use each surface, see [Herald and GitHub Releases](/guides/herald-and-github-releases/).) This is the part most of the category isn't built around — reading your PRs to draft, _and_ publishing the finished release back to GitHub. Other tools position differently; Herald centers the PR-to-changelog-to-GitHub-Releases loop specifically. Ready to try it on your own repo? [Start a 14-day Herald trial](https://app.sendherald.com/sign_up) — no credit card — connect a repo, and draft a release from your last 30 days of merged PRs. ## The gap all three share Whichever method you pick, the quality of the changelog is capped by the quality of the inputs. A changelog generated from PRs titled `fix stuff` and `update deps` will read like exactly that. The single highest-leverage thing you can do — before adopting any tool — is make your PRs describe what changed in a way a human (or an AI) can turn into a useful entry. ## Make your PRs changelog-ready These habits improve the output of GitHub's native notes, a GitHub Action, and an AI tool alike: - **Write PR titles like changelog entries.** "Add CSV export to the reports page" beats "reports v2". The title is the line most generators reach for first. - **Use labels consistently.** Label PRs `feature`, `fix`, `breaking`, etc. Every grouping method above keys off labels to sort entries into sections. - **Squash-merge** so each PR becomes one meaningful commit. This keeps commit-based generators clean and avoids noise from work-in-progress commits. - **Put user-facing context in the PR description.** Even one sentence on _why_ a change matters gives an AI draft something real to work from — and reminds future-you what the change was for. - **Mark breaking changes explicitly.** A `breaking` label or a "BREAKING CHANGE" note in the description ensures the most important entries never get buried. (See [breaking change](/glossary/breaking-change/) and the difference between a [changelog and release notes](/glossary/changelog-vs-release-notes/).) Good PR hygiene is the cheapest changelog automation there is — it makes every downstream tool better for free. ## Common questions **Can I generate a changelog from PRs without writing any code?** Yes. GitHub's built-in "Generate release notes" button (Option 1) needs no code at all, and an AI changelog tool like Herald reads your PRs through a connected repo with no scripting. GitHub Actions (Option 2) require a small config file but no application code. **What's the difference between generating release notes and a customer-facing changelog?** [Release notes](/glossary/release-notes/) generated from PRs are typically written for engineers and live in your repo. A customer-facing changelog re-frames the same changes in plain language for the people who use your product, on a hosted page, widget, or email. The source data is the same; the audience and surface differ. **Do I need Conventional Commits to generate a changelog?** No. Conventional Commits make commit-based generators fully automatic, but GitHub's native notes and AI tools work from PR titles, labels, and descriptions regardless of your commit style. **How does Herald decide what goes in the changelog?** You choose the source — merged PRs since a date, a branch comparison, or a release/tag comparison — and Herald's AI drafts entries from the PR titles, descriptions, and labels in that range. You review and edit before anything publishes. Full setup is in the [GitHub integration docs](/docs/github/). --- Stop hand-writing the customer version of notes you already wrote as PRs. [Start a free 14-day Herald trial](https://app.sendherald.com/sign_up), connect your repo, and let AI draft your changelog from your merged pull requests. Next guide: [Herald and GitHub Releases — when to use each](/guides/herald-and-github-releases/)