Automatic Changelog from GitHub

Changelogs die in the gap between "we should write this down" and "we already shipped three more things."

An automatic changelog from GitHub is the practical fix: treat git history as the source of truth, transform it into human-readable notes, and stop relying on memory the night before a release.

This guide is for indie builders who want users (and future-you) to understand what changed—without inventing a documentation department.

Why changelogs still matter when you move fast

Speed without a paper trail creates support debt. Users ask "did this break?" Partners ask "what is new?" You ask "when did we change that default?"

A changelog is not marketing fluff. It is:

• A trust surface for people who already pay or are about to.
• A debugging aid when behavior shifts.
• A narrative of the product that outlives chat threads and tweet storms.
• Input for other channels—social posts, release emails, and shipping blogs all get easier when the change list exists.

If you already share progress publicly, a changelog is the structured twin of build-in-public posts. See how to build in public as an indie hacker for the cultural half; this piece is the operational half.

What "automatic" should and should not mean

Automatic does not mean "dump git loginto a markdown file and call it done."

Users cannot parse a wall of fix typo and wip. Automatic should mean:

1. Collect commits, PRs, or tags in a defined window.
2. Filter noise (merge commits, dependency bumps you do not want listed, bot noise).
3. Group by theme or type (features, fixes, breaking).
4. Rewrite into plain language when needed.
5. Publish somewhere durable: repo file, docs site, product UI, or public build log.

Steps 1–2 are easy to script. Steps 3–5 are where most DIY pipelines get ugly—and where human review still earns its keep for major releases.

Conventional commits help, but they are not required

If your team (or solo self) can adopt a simple commit convention, automation gets sharper:

• feat: user-visible additions
• fix: corrections
• perf: performance
• docs: documentation only
• chore: maintenance

Tools and scripts can group these automatically. Many open-source release helpers assume this shape.

If you cannot adopt a convention yet, you still have options:

• Group by path or package.
• Group by linked issue labels.
• Use AI or templates to rewrite messages into user language, then review.
• Publish a coarser daily shipping note instead of a formal versioned changelog.

Perfect structure is optional. Continuity is not.

DIY approaches that actually work

1. Tag-driven generation

On each git tag, a script collects commits since the previous tag and writes CHANGELOG.md. This is the classic open-source pattern. It fits versioned libraries and apps with real release boundaries.

Strengths: clear versions, reproducible history.
Weaknesses: continuous deployers who rarely tag must invent artificial versions or switch to date-based logs.

2. Pull request titles as the unit

Some teams treat merged PR titles as the changelog line items and ignore individual commits. That works when PRs are small and well named. It fails when everything lands as misc fixes on a Friday.

3. GitHub Actions on a schedule

A scheduled workflow can open a PR that updates the changelog draft from the last N days. You merge when it looks right. Good middle ground between full auto and full manual.

4. Docs site or product "What's new"

Writing only to CHANGELOG.md in the repo is necessary but not always sufficient. Users who never open GitHub need an in-app or docs page. Generate the markdown once, render it in multiple places.

5. Free generators for one-off cleanups

If you need a starting point from existing history, a changelog generator can help you prototype structure before you wire automation.

None of these require a SaaS. All of them require taste: what users should see versus what developers needed to say in the moment.

Writing for humans after the machine drafts

Whether a script or a model drafts the text, apply a release-editor pass for anything user-facing:

• Lead with impact."Faster project export" beats "refactor export worker."
• Call out breaking changes explicitly. Burying them is how you lose trust.
• Name the audience. Admin-only changes can live under a quieter heading.
• Avoid internal codenames unless users already know them.
• Link to docs when a feature needs more than one line.

For public distribution beyond the changelog file, GitHub commits become blog posts covers turning shipping days into longer articles.

Daily shipping logs vs versioned changelogs

Solo founders often need both formats:

An automatic pipeline from GitHub can feed all three if you keep the raw capture clean: commits in, structured notes out, then format-specific templates.

Date-based logs pair well with continuous shipping. Versioned changelogs pair well with anything installable or anything enterprise buyers will read carefully. Many products keep a short "What's new" for humans and a detailed file for operators.

Privacy, monorepos, and multi-product repos

Automation gets messy in real repos.

Monorepos: scope the changelog to paths that map to a product. Users of product A do not need every package B chore.

Public vs private history: if the repo is private, the changelog you publish externally must not leak internal ticket titles or customer names that appeared in commit messages. Filter ruthlessly.

Multiple products in one GitHub account: separate output streams. One automatic changelog that mixes three products confuses everyone.

Bots and dependency PRs: decide a policy. Some maintainers include dependency updates in a collapsed section; others omit them from the user-facing log entirely.

How gittomarket uses shipping history (not a classic CHANGELOG.md)

gittomarket is not a drop-in replacement for Keep a Changelog files inside your repo. It is adjacent infrastructure: it turns each day of GitHub commits into public shipping artifacts.

Each morning it builds designed stat cards from the previous day's commits and can auto-post to X, LinkedIn, and Bluesky (skipping zero-commit days). Captions target a customer description you set once; approve via Telegram or fully auto-post. It reads only commit counts and messages, never code.

Those same shipping days feed a public build page (gittomarket.io/w/your-slug or custom domain via CNAME) with a waitlist and SEO-indexed articles auto-written from each day you ship. See /w/gittomarket for a live example. Free includes 10 auto-posts/month and a 14-day full Pro trial without a card; Pro is $29/month; founding beta is $9/month forever for the first 20 seats (pricing). CLI (g2x) and MCP support posting from terminal or AI editors.

If you need a formal in-repo changelog, keep generating that from tags or PRs. If you need the public narrativeof shipping to stay continuous, a build page and daily articles cover a different job—and they pair well with a classic changelog rather than replacing it.

A minimal system you can maintain alone

For a solo founder, this is enough:

1. Write commit messages for strangers. Future automation will quote them.
2. Tag releases when something is user-shippable, even if you deploy daily.
3. Auto-draft notes from commits since the last tag (Action or local script).
4. Edit for 10 minutes before publishing user-facing text.
5. Mirror the result to docs or a build page so non-GitHub users can read it.
6. Reusethe same draft for a short social update if you build in public—see marketing for developers who hate marketing for keeping that light.

Optional upgrade: conventional commits once the habit sticks.

Common failure modes

• Auto-publishing unfiltered logs. Noise trains users to ignore you.
• Only updating on big launches. You recreate the memory problem.
• Changelog as marketing only. If it never mentions fixes and regressions, people stop believing it.
• No home outside the repo. Half your audience will never see CHANGELOG.md.
• Over-automation without a break-glass review on breaking changes.

For tooling landscape context, best build in public tools for 2026 surveys related distribution options.

Bottom line

An automatic changelog from GitHub is less about fancy AI and more about a reliable pipeline: capture history, filter noise, rewrite for humans, publish somewhere people look. Start with tags or daily windows, keep a short human edit for anything that can break users, and let the machine handle the part humans always postpone.

The goal is not a perfect file. The goal is that "what changed?" never depends on your memory again.