How to generate a changelog from git log without an LLM

Most "AI changelog generator" tools work the same way: they take your recent commits, send them to an LLM API, and ask it to write prose. That costs a network round trip, an API key, and a per-run bill — and the output is non-deterministic, so the same commits can produce a different changelog on two different runs.

If your commit messages already follow Conventional Commits (feat:, fix:, perf:, and so on), you don't need any of that. The type is already in the message. A changelog generator's real job is just: parse, group by type, detect breaking changes, and pick a semver bump. That's a text-processing problem, not a language-generation problem.

The rule for picking a semver bump

Given a set of commits since the last tag:

Any commit marked breaking (feat!:, or a BREAKING CHANGE: footer) → major
Otherwise, any feat: commit → minor
Otherwise, any fix: or perf: commit → patch
Otherwise (only chore:, docs:, test:, etc.) → no release needed

This is exactly the rule semantic-release and similar tools use — it's deterministic, so two people (or two CI runs) parsing the same commit range always get the same answer.

Doing it with plain git

You can get the raw material with one command:

git log v1.2.0..HEAD --pretty=format:"%s%n%b%x00"

Then, per commit: split on the first : to get type(scope)! vs. the subject, check the body for a BREAKING CHANGE footer, bucket by type, and apply the rule above. That's the entire algorithm — no model call needed anywhere in it.

Using gitrecap instead of writing this yourself

If you'd rather not write and maintain that parser, gitrecap is a free, MIT-licensed script that does exactly this: it runs git log locally, groups commits by Conventional Commits type into a Markdown changelog, and prints the suggested next version — with no API key, no network call, and no LLM in the loop.

curl -O https://shop.intirama.com/dl/gitrecap.py
chmod +x gitrecap.py
./gitrecap.py --version-suggest

Note: this only works well if your team already writes Conventional Commits. If your history is mostly free-text messages like "fix stuff" and "wip", no parser — including an LLM-based one — can reliably recover intent that was never recorded. The fix is upstream: adopt a commit convention going forward, not a smarter changelog tool.

Beyond changelogs: release safety

A correct changelog and version bump only tells you what changed. It doesn't tell you whether a migration in that release is safe to run against production, whether a dependency bump introduces breaking behavior, or how to write a blameless postmortem after something goes wrong anyway. Those are the harder, more judgment-heavy calls around a release — covered in the Claude Code Power Pack if you want skills for that side of shipping. If your CI is also fighting intermittent failures, see the companion guide on diagnosing flaky tests; if this release includes a schema change, see the one on safe database migrations; if it bumps a dependency, see the one on dependency upgrade risk; if something still went wrong, see the one on blameless postmortems.