How to generate release notes from GitHub pull requests
Turn merged GitHub pull requests into accurate, customer-facing release notes with a repeatable workflow for product and engineering teams.
Merged pull requests are one of the best sources for release notes: they explain what changed, include review context, and usually represent work that is actually ready to ship. The problem is that PRs are written for collaborators, not for customers.
This workflow helps a GitHub-native SaaS team turn completed PRs into accurate release notes without copying a technical activity log into a public changelog.
1. Decide what counts as one release
Start with a release window your team can explain. For a weekly release, that might be every customer-facing PR merged since the previous Friday. For a larger launch, it might be one feature branch and its supporting fixes.
Do not include every merge automatically. Exclude work that is still behind a feature flag, internal-only maintenance, reverted changes, and duplicate PRs. Release notes should describe what customers can use now.
| Include | Usually leave out |
|---|---|
| A new capability customers can use | Internal refactors with no visible change |
| A fix to a customer-facing workflow | Dependency updates with no customer impact |
| A meaningful reliability or performance improvement | PRs that were reverted or are still behind a flag |
| An important behavior or policy change | Duplicate or follow-up implementation PRs |
2. Read PRs for the outcome, not only the title
A title tells you where to start. The description, linked issue, screenshots, and review discussion tell you whether the work changed the product experience.
For example, these are useful source notes:
| Merged PR | What the team knows | What a customer needs to know |
|---|---|---|
#412 Add saved customer list views | Persists filters in the list UI | Reopen the customer views you use most often |
#417 Avoid duplicate account-owner notifications | De-duplicates notification jobs | Receive fewer repeated account notifications |
#421 Stream large CSV exports | Moves export processing off the request path | Export larger customer lists more reliably |
The third column is the raw material for the release note. It names a real outcome without inventing a marketing claim.
3. Group related work before you write
Customers do not need one changelog item per pull request. Group supporting PRs under the feature or workflow they improve. A useful rule is: one section for each customer-visible job that became easier, safer, or newly possible.
The three PRs above might become two sections:
## Easier customer list workflows
Save the customer-list filters you return to most often, then reopen them
without rebuilding the same view each time.
## More reliable account operations
Account owners receive fewer duplicate notifications, and larger customer-list
exports are more reliable.
That is more useful than a list of issue IDs because it gives the update a structure a customer can scan.
4. Write the first draft in customer language
Use this simple shape for each item:
- Headline: name the new capability or improved workflow.
- Outcome: say what people can do now or what is more reliable.
- Context: include one useful detail when it helps customers recognize the change.
- Next step: point to setup instructions, the product area, or a related announcement when needed.
Avoid phrases such as “refactored,” “fixed edge case,” or “improved the service layer” unless the reader is a developer who needs that implementation detail. They explain how the work happened, not why it matters.
5. Keep human review in the workflow
Automation can find merged PRs and build a strong first draft, but a person still needs to check scope, names, and timing. Before publishing, ask:
- Is every feature available to the audience reading this update?
- Does the headline match the terminology in the product?
- Did we remove sensitive implementation or customer information?
- Is there a clear next step for a customer who wants to try it?
For a more detailed final pass, use the release notes checklist.
6. Publish from one source of truth
Once the release note is approved, publish it to a durable changelog page first. That page can become the source for an in-app update, email digest, social post, or customer conversation. It prevents each channel from drifting into a different version of the same announcement.
Changelog Generator uses merged GitHub pull requests as source material, drafts customer-facing updates, and lets your team edit the final version before publishing it to a hosted changelog.
Next: use the GitHub release notes templates when you need a ready-made structure, or see a complete GitHub changelog example.
Generate an editable release-note draft from GitHub pull requests.