Why are merged pull requests better than git commit logs for changelogs?

Raw git commits contain work-in-progress messages ('fix typo', 'wip'). Merged pull requests represent reviewed, tested units of work with clear titles and associated discussion.

How do you filter out bot PRs like Dependabot or Renovate?

Filter by author association or author login. Exclude `app/dependabot`, `app/renovate`, or pull requests labeled `dependencies` from user-facing notes.

How does squash-and-merge affect changelog extraction?

Squash merging creates a single canonical merge commit on the target branch. The GitHub API preserves the PR title, number, and `merged_at` timestamp regardless of merge strategy.

Can GitHub Release tags trigger changelog generation?

Yes. A webhook on the `release` event (`action: published`) can trigger immediate changelog compilation for the tag's milestone window.

How to Build a Product Changelog from Merged GitHub Pull Requests

Turn merged PRs, release tags, and closed issues into customer-facing release notes. Avoid raw commit noise with deterministic label grouping.

Soobrief Team — Product & Engineering, Sooapps · 2026-08-20

In short

Building a customer-facing changelog from GitHub requires filtering pull requests by `merged_at` timestamps on the production branch, ignoring unmerged PRs, and grouping changes by PR labels or semantic prefixes. This eliminates raw git commit noise and produces clean, human-readable release notes.

Building a customer-facing changelog from GitHub requires filtering pull requests by merged_at timestamps on the production branch, ignoring unmerged PRs, and grouping changes by PR labels or semantic prefixes. This eliminates raw git commit noise and produces clean, human-readable release notes.

Git repositories contain the ground truth of what actually shipped. However, dumping raw git commit logs into a changelog results in unreadable noise like "fix lint", "wip", or "rebase master" that confuses customers and stakeholders.

1. The Right Signal: Merged Pull Requests, Not Commits

A pull request represents a reviewed, validated unit of delivery. The correct GitHub API query targets merged pull requests targeting the default branch:


GET /repos/OWNER/REPO/pulls?state=closed&base=main&sort=updated&direction=desc

In the response payload, inspect:

merged_at: Must not be null (discarding closed without merge).
base.ref: Must match your production deployment branch (e.g. main or production).
user.login: Must not be an automated bot (unless aggregating dependency updates into an internal section).

Strategy	Advantages	Pitfalls
Git Commit Log	No API required	Full of noise, duplicate merges, and WIP commits.
Merged Pull Requests	Structured, reviewed, includes descriptions & labels	Requires GitHub API token or App installation.
GitHub Releases	Official milestone record	Infrequent cadence for continuous deployment teams.

2. Grouping PRs with Semantic Labels

To turn PR titles into structured release notes, enforce PR labeling in your repository:

Labels feature, enhancement: Placed under New Features.
Labels bug, fix: Placed under Bug Fixes & Stability.
Labels security, perf: Placed under Performance & Security.
Labels internal, chore, dependencies: Filtered into internal developer digests.

3. Webhooks and Automated Digesting

By installing a GitHub App with permissions for pull_requests: read and contents: read, Soobrief receives pull_request events where action == "closed" and merged == true. The update is indexed in milliseconds, ready for your weekly summary.