How to Generate a Changelog from GitHub Commits (2026 Guide)

Every software project accumulates commits, but very few turn those commits into something users actually want to read. If you have ever scrolled through a raw git log trying to piece together what changed between releases, you already know the problem. Commits are written for developers. Changelogs are written for humans.

The good news is that generating a changelog from GitHub commits no longer requires hours of manual work. In 2026, you can choose from AI-powered platforms, CLI tools, and GitHub Actions that parse your commit history and produce structured, readable release notes in minutes or even seconds.

This guide walks through the five most practical methods, compares them side by side, and helps you pick the right approach for your workflow.

#Why Commits Alone Are Not Enough

Raw commit messages are noisy. A typical feature branch might include dozens of commits like "fix lint," "WIP," "address review feedback," and "actually fix the thing." Dumping all of that into a changelog confuses users and buries the changes that matter.

A good changelog does three things a raw commit log does not:

• Groups related changes so readers can scan quickly
• Uses customer-friendly language instead of developer shorthand
• Highlights what matters by separating features, fixes, and breaking changes

The tools below solve this translation problem in different ways.

#Changelog Generation Tools Compared

#Tool Breakdown

#1. ShipTell: AI-Powered Changelog from GitHub Commits

ShipTell connects to your GitHub repositories through a GitHub App. Once installed, it reads your pull requests, commits, labels, and issues, then uses AI to cluster changes by intent and write readable changelog entries. The entire process takes about three minutes from connection to published changelog.

What sets ShipTell apart from CLI tools is the output quality. Instead of dumping commit messages into a list, the AI understands that five commits about "payment flow" belong together and writes a single, coherent entry like "Improved checkout reliability with better error handling for failed payment attempts."

ShipTell also solves the distribution problem. Your changelog lives on a public page you can share, but you can also embed it as a sidebar drawer, widget, or modal popup directly in your app. Users see what changed without leaving your product.

Best for: Developers, indie hackers, and SaaS founders who want polished changelogs without writing a single word.

Pricing: Free tier includes 5 changelogs per month. Pro is $19/month or $190/year.

Limitation: Currently GitHub-only, so teams on GitLab or Bitbucket will need to wait for future integrations.

#2. github-changelog-generator (CLI)

This Ruby-based CLI tool has been around for years and remains popular in open-source projects. It pulls data from the GitHub API, including issues, pull requests, and tags, then generates a CHANGELOG.md file grouped by version.

Installation and usage:

 1gem install github_changelog_generator
 2github_changelog_generator -u your-username -p your-repo --token YOUR_GITHUB_TOKEN

The tool creates a Markdown file with sections for each tagged release. It categorizes entries based on labels like "bug," "enhancement," and "breaking change." If your issues and PRs are well-labeled, the output is decent. If they are not, you get an unsorted list.

Best for: Open-source projects that already use GitHub labels consistently and want a simple CHANGELOG.md in their repo.

Downside: No AI processing, no public changelog page, and output quality depends entirely on how disciplined your labeling is.

#3. Release Drafter (GitHub Action)

Release Drafter runs as a GitHub Action and automatically drafts release notes every time a pull request is merged. It uses a configuration file to map PR labels to changelog categories.

Setup:

Create .github/release-drafter.yml:

 1name-template: 'v$RESOLVED_VERSION'
 2tag-template: 'v$RESOLVED_VERSION'
 3categories:
 4  - title: 'Features'
 5    labels:
 6      - 'feature'
 7      - 'enhancement'
 8  - title: 'Bug Fixes'
 9    labels:
10      - 'fix'
11      - 'bugfix'
12  - title: 'Maintenance'
13    labels:
14      - 'chore'
15      - 'dependencies'

Create .github/workflows/release-drafter.yml:

 1name: Release Drafter
 2on:
 3  push:
 4    branches: [main]
 5permissions:
 6  contents: read
 7  pull-requests: write
 8jobs:
 9  update_release_draft:
10    runs-on: ubuntu-latest
11    steps:
12      - uses: release-drafter/release-drafter@v6
13        env:
14          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Each merged PR with a matching label gets added to the draft release. When you are ready to ship, you publish the draft.

Best for: Teams already using GitHub Actions who want release notes tied to their PR workflow.

Downside: Requires label discipline. PRs without labels get dumped into an "uncategorized" bucket. No AI rewriting, no public page.

#4. Conventional Changelog (Node CLI)

If your team follows the Conventional Commits specification (e.g., feat:, fix:, chore:), this tool parses those prefixes and generates a structured changelog automatically.

Setup:

 1npm install -g conventional-changelog-cli
 2conventional-changelog -p angular -i CHANGELOG.md -s

The -p angular flag uses the Angular commit convention, which is the most common. The tool scans your git history, groups commits by type, and appends them to your CHANGELOG.md.

Best for: Teams that already follow conventional commits and want zero-config changelog generation.

Downside: Only works if every contributor follows the commit convention perfectly. One "fixed stuff" commit breaks the pattern. No AI cleanup.

#5. Manual with git log

The simplest approach is a filtered git log command:

 1git log --oneline --no-merges v1.0.0..v1.1.0

You can pipe this into a file and edit it manually. Some teams add formatting:

 1git log --pretty=format:"- %s (%h)" --no-merges v1.0.0..v1.1.0 > CHANGELOG_DRAFT.md

Best for: Quick, one-off changelogs when you just need something right now.

Downside: You are the AI. Every entry needs manual editing, grouping, and cleanup.

#Step-by-Step: Generate a Changelog with ShipTell

1. Sign up at shiptell.com and connect your GitHub account
2. Install the GitHub App on the repositories you want to track
3. Select a repository from your dashboard
4. Click "Generate Changelog" and ShipTell reads your recent PRs, commits, labels, and issues
5. Review the AI-generated draft which groups changes by intent (features, fixes, improvements)
6. Edit if needed and publish to your public changelog page
7. Embed in your app using the sidebar drawer, widget, or modal popup

The first changelog takes about three minutes. Subsequent ones are faster because ShipTell knows your project context.

#Decision Framework: Which Method Should You Use?

Choose ShipTell if you want polished, user-facing changelogs without manual writing and you need distribution features like embeddable widgets and public pages. Ideal for SaaS products, indie hackers, and startups.

Choose Release Drafter if your team already labels PRs consistently and you want release notes drafted automatically inside GitHub Releases.

Choose Conventional Changelog if your entire team follows conventional commit messages and you just need a CHANGELOG.md in your repo.

Choose github-changelog-generator if you maintain an open-source project and want a simple CLI that produces a standard CHANGELOG.md from your GitHub issues and PRs.

Choose manual git log if you ship rarely, have a small project, and just need a quick list.

#Stop Writing Changelogs Manually

The gap between committing code and communicating changes to users should not take hours. Whether you pick an AI-powered tool like ShipTell or a CLI generator, automating your changelog saves time and ensures your users actually know what you shipped.

If you want the fastest path from GitHub commits to a published, shareable changelog, try ShipTell for free. Connect your repo, generate your first changelog in three minutes, and start keeping your users in the loop.