How do you build a "What's new" page generated from git?

You generate a "What's new" page from git by deriving two things from the diffs rather than one: the entry (what changed, stated in user language) and the window (since when). The window is the part teams forget, and it is what separates this page from a published changelog: a changelog slices time by release, a "What's new" page slices it by visit.

The distinction sounds cosmetic. It decides what you have to generate, what you have to leave out, and why so many of these pages die three months after launch.

Three artefacts, one source

Three pages look alike and do different jobs. Sorting them out before writing a line of generator code keeps you from shipping one that serves nobody.

That last row is the hard one. A six-month-old changelog is still correct, because it never claimed anything beyond recording facts in order. A six-month-old "What's new" page is wrong: its title promises news that its contents contradict.

We covered the chronological artefact in automating a changelog from git history, and the language of customer-facing notes in release notes your customers actually read. This article does not replay them. It takes the surface with a constraint of its own: freshness, and a reader whose window matches no release.

"What changed since my last visit?"

That is the question your reader is asking, word for word, and no release answers it.

Someone returning after five weeks away is not looking for v2.7. They are looking for the gap between the product they remember and the one in front of them. That gap cuts across four releases, ignores three quarters of their contents, and cares nothing about where the version boundaries fell.

A generator that slices by git tag will never produce that answer. It returns blocks, and the reader is left to do the arithmetic. Most of them don't. They skim, recognise nothing, and close the tab.

Generating from git therefore means answering over an arbitrary window: thirty-seven days, two weeks, since last Tuesday. Commits carry that information natively, because they are timestamped one by one. Version tags aggregate it, and so lose it.

What to derive from the diffs

Three things, in this order.

The fact. What changed in the product's behaviour, not the commit message. A message says fix: date parsing in export; the diff says the export now accepts a date format it used to reject, which is the only phrasing a user recognises. Messages are written for the team; diffs are the facts.

The scope. Not every change deserves a line on this page. An invisible internal fix has no business there; a change to a default behaviour does. The diff gives you a good first pass at that call, since anything touching a user-facing surface stands out. It does not give you the right one every time.

The date. Every entry carries its own. That property, and only that one, lets you serve any window later without rewriting anything. A page whose entries are dated individually can answer "since my last visit"; a page organised into version blocks cannot.

A page has a URL, and that changes things

This is the property an internal changelog lacks, and it has two consequences.

First, the page is indexable. People find it by searching whether your product still does a given thing, or what moved since a trial last year — traffic no marketing page catches.

Second, answer engines read it. When an assistant has to say what recently changed in a product, this page is often its only fresh material. Stale, it teaches the assistant the opposite of the truth, with the authority of an official source.

It is the same mechanism described in why AI agents need release awareness: the window right after a release is when every frozen body of knowledge starts to lie, and this page joins them the moment you stop feeding it.

The triage that does not go away

Here is the part a sales piece would skip. Generating entries from diffs removes the writing, not the judgement.

In an ordinary week, an active product piles up dozens of changes, three of which are worth announcing. Automatic ranking does the first pass. What it cannot know is that the fourth change, technically trivial, is the one a customer emailed you about three times. What remains is a few minutes of review, not an hour of writing.

That is where the gain actually shows: the cost moves from "write" to "approve". A team that used to draft three paragraphs now ticks or discards entries that are already phrased and already dated. That shift is what keeps a "What's new" page alive past its third month, and claiming more would be claiming that editorial judgement disappears, which no generator makes it do.

"We already have a changelog, we'll publish it as a page"

That is what most teams do, and it works for a while. Two things then show up.

A changelog is written for someone who knows the product from the inside. Published as is, it asks a user to translate refactor or bump into practical consequences. The reader coming back after five weeks does not make that translation.

More importantly, the changelog keeps its per-release window. Stacking versions in order is what makes it a good register and a poor answer to the reader's question. If you only keep one of the two pages, keep the changelog: it is verifiable and it does not go stale. Just don't ask it to do the other one's job.

A public page derived from a private repository: where is the line?

It runs between what gets read and what gets published, and it deserves to be spelled out, since we are asking for access to a repository in order to build a page meant for everyone.

The GitHub connection is read-only, revocable at any time, and the code is resynchronised on every push. One project, one server. What comes out is not source code: it is entries in user language, backed by the commits they are drawn from, which lets you check every published line before it goes out. The details live on our security page.

DeployIt monitors no one and prevents nothing: it is a read-only service that derives pages from what it reads. Documentation generated from your code and the MCP server that answers your agents are two views of the same source — one for your human readers, one for the agents plugged into your product.

What this page does not solve

It does not replace an announcement. A major change deserves an email, a post, a demo. This page is where people verify, not where they find out.

Nor does it document: it says what changed, never how to use it. That work belongs to the help center, and we described elsewhere how to keep it in sync with every release.

Finally, it will say nothing about what does not go through git. A pricing change, a vendor-side change, a commercial decision: none of these has a diff.

Mini-FAQ

In the product or on the public site? Each has a real advantage: the panel knows the signed-in reader's last visit date, the public page is indexable and citable. The question is not which to pick, but how to avoid writing both.

Date entries by release or by commit? By commit. You can always group finely dated entries; you can never re-slice a version block.

How many entries per week? No rule, and be wary of the ones going around. A week with nothing worth announcing does fine with no entry; a page that publishes filler teaches its readers to stop opening it.

What about security fixes? They follow your disclosure policy, not automatic generation. This is the textbook case where an entry derived from a diff gets reviewed before it is published.

What to take away

A "What's new" page is not a better-looking changelog. It is a page answering a question whose window belongs to the reader, and that constraint shows up at generation time: you need individually dated entries, phrased from the diffs, and triage you accept doing.

The three artefacts in this piece come from the same place, your git history. That is why deriving them costs less than writing them. DeployIt is free during early access; paid plans arrive in January 2027.