You can automate a changelog from git history with two families of tools: generators that parse commit messages (git-cliff, release-please, GitHub's and GitLab's automatic release notes), and a newer approach that derives the changelog from the real diffs. The first family needs strict naming discipline to produce anything readable; the second holds up even when half your commits are named "wip", and produces a changelog your customers can read — and your AI agents can query.
This guide walks through the classic tools, then applies a simple test: the list of questions your changelog is supposed to answer. That test is what separates the two approaches.
What changelog automation actually means
Changelog automation: producing and maintaining, with no manual writing, the dated list of what changes in a product — new features, fixes, deprecations — from the source of truth: the project's git history.
The key word is "source". A hand-written changelog drifts the second time someone forgets a release. A generated changelog doesn't drift: it is recomputed from git at every version. The whole question is what the tool reads inside git.
The classic tools: what they read, what they produce
On GitHub, the "Generate release notes" button compiles the titles of pull requests merged since the last release, plus new contributors. GitLab offers the equivalent through its API. It's free, built in, and faithful to whatever your PR titles say.
One step up, git-cliff and release-please build on conventional commits (feat:, fix:, feat!:): the first generates a changelog grouped by change type; the second also derives the version number and opens a "release PR" that publishes everything on merge. For a disciplined repository, this is excellent tooling.
The contract is written in their docs: these tools read messages — commit or PR — never the content of the changes. The changelog you get is an exact copy of your naming discipline. Rigorous team, useful changelog. Rushed commits, and the changelog lists "fix", "update", "wip" and leaves the reader guessing.
The test: five questions your readers ask
Nobody reads a changelog for its own sake. People (and agents) read it looking for the answer to a question. Here are five, heard verbatim from support, customer success and integration teams:
- What changed since the last release? The baseline. Message-based generators answer it, provided PR titles are good.
- Did the API change this week? The integrator's question: an unannounced breaking change gets discovered in production. A well-labeled
feat!:commit flags it; a commit named "update endpoints" never will. - Why did this behavior change? The post-release mystery ticket. The answer isn't in the commit message: it's in the diff, the one that shows which condition changed and with what intent.
- Is this new, fixed, or deprecated? The sorting conventional commits promise, as long as every commit is correctly typed at the moment it's written.
- What's new for my customer? The customer success question, which needs an answer in customer language, not a list of PRs.
Run your current changelog through the test. If it answers all five, keep your tooling. If it answers the first and leaves the other four to a developer someone has to interrupt, the limit isn't your discipline: it's the layer the tool reads.
Ready to see what your team shipped?
Generating from diffs: the changelog as a view
The approach DeployIt takes inverts the source. DeployIt reads your real code (resynced on every push), your git history (commits + diffs) and the customer's data through its own MCP servers, and checks the code before asserting anything. The changelog then becomes a generated view: the same source that answers the questions above also produces the dated list of changes, in customer language, with breaking changes flagged from the content of the diffs rather than from a ! someone remembered to type.
Two practical consequences:
- The changelog holds without naming discipline. Diffs are exact by construction: they are what the machine executes. A "wip" commit that changes an export's default sort order produces an entry about the default sort order, not a line that says "wip".
- One source, several surfaces. Public changelog, internal note, a help center answer: views of a single source, never rewritten three times. And the window stays open for questions: whatever the view doesn't show, you ask.
Publishing tools (Beamer, LaunchNotes, Headway) stay useful in this setup: they are announcement channels. They distribute content; generation from git hands them content that doesn't wait for a human to write it.
On comparable tools: Context7 and DeepWiki cover libraries and public repos; Mintlify generates an MCP from written docs; DeployIt covers your private product, derived from the code itself, fresh on every deploy.
Your agents read the changelog too
Your readers are no longer all human. A support bot answers from knowledge frozen at indexing time; every release makes it a little more wrong. A changelog derived from git, exposed through an MCP server (in early access / design partner program), gives those agents the same freshness humans get: they can check what changed before answering, instead of asserting last month's state.
The same mechanism answers "Did the API change this week?" when the asker is an integration agent. The changelog stops being a page; it becomes a capability.
"We already use conventional commits, that's enough"
If every commit on your team is well typed and well titled, that's true: git-cliff or release-please give you a reliable changelog for zero extra effort, and GitHub's official MCP server additionally lets a tooled-up developer query the repository. Keep that tooling.
The difference shows up in two cases messages don't cover. First, commits that lie or say nothing: a diff-derived changelog stays correct when discipline slips, on an ordinary release Friday. Second, readers without repository credentials: a customer, a contractor, an agent platform like Intercom Fin. GitHub's server requires repo access per asker; a changelog-as-view and a queryable expert serve those readers without opening the code to them.
What about repo access in this setup?
DeployIt reads your repository to generate these views, and that connection has a defined scope: GitHub read-only, one server per project, revocable at any time. Answers and changelog entries cite commits and diffs, with no raw source reproduction: what leaves is the answer, not your code. Auditing the connection takes two clicks in your GitHub settings.
Mini-FAQ
Should we drop git-cliff or release-please? Keep them if your commits are disciplined: they are good tools, deterministic and free. Diff-based generation complements them where they stop (badly named commits, customer language, readers without repo access).
What happens to our CHANGELOG.md? It can remain the output format. What changes is upstream: its content is derived from diffs instead of written by hand or compiled from messages.
What about a monorepo? The per-project principle applies: one server and one set of views per product, so one product's changelog doesn't mix in another's changes.
Where are the numbers in this article? There aren't any, on purpose: no customer figures are quoted here, and the cases described (the "wip" commit, the export whose sort order changes) are illustrative.
Where to start
Write down the five test questions and look at who asks them: if it's humans without repo access, or agents, message-based generation won't serve them. DeployIt is free during early access (paid plans come in January 2027): connect a repository, ask the five questions, compare with your current changelog. To go deeper on the release-notes layer, read what AI release notes generators actually read; for the live-question version, here is what "what changed in the product this week?" looks like when you ask it directly.
Continue reading
Why Did This Behavior Change? Answers From Your Git History
The product works, just differently than last week: the post-release mystery ticket. Trace the symptom to the diff that explains it, no interruptions.
How to Let AI Work on Client Code Without Breaching the NDA
Contractors, AI agents, and support teams need answers about a client's product under NDA, not its code. How to split the two flows.
AI Release Notes Generator: What These Tools Actually Read
What release notes generators actually read — git-cliff, release-please, AI layers — and the approach that derives notes from real diffs.