Keeping your users in the loop about new features, bug fixes, and improvements is essential for a great product experience. GitDocAI builds your changelog for you from your GitHub repo and gives you two components to refine the result afterward.

Generating changelogs from GitHub Releases

To build a changelog in GitDocAI, start by connecting a GitHub repository as the source of a Changelog section. GitDocAI reads your GitHub Releases and creates one page per release.

Unlike API reference generation — which is deterministic — changelog generation runs your release bodies through an AI pass. Raw GitHub release notes tend to be terse and developer-facing ("bump deps, fix null check in handler"); GitDocAI rewrites them into concise, user-friendly language that describes what changed from the reader's perspective. The underlying release data (tag, date, author, link) stays untouched — only the prose is rewritten.

1. 1

   Create a Changelog section

   Add a new section to your documentation and pick Changelog as the section type.

2. 2

   Connect your GitHub repository

   Attach a repository as the section's source, set content source to Releases, and GitDocAI will pull every release from the GitHub Releases API. See Importing Content Sources for the full connection flow.

3. 3

   Review and refine

   GitDocAI generates one page per release, with the body rewritten in a friendly tone. Open any entry to see the <Changelog> and <Update> components below — those are the primitives every changelog page is built from, and you can edit them freely.

Understanding the structure

A generated changelog page uses two components working together: a <Changelog> container that holds the whole page, and one <Update> block per release.

flowchart TD
    A["<Changelog> container"] --> B["<Update> v2.1.0"]
    A --> C["<Update> v2.0.0"]
    A --> D["<Update> v1.9.0"]
    B --> E["Release body (Markdown, components)"]

Customizing the generated pages

Changelog (container)

Wraps the entire page and sets the top-of-page heading. Inside it, you place one <Update> per release.

Attributes: title (optional), description (optional).

MDX:

<Changelog title="Release Notes" description="Everything new in our platform.">
  <Update label="April 15, 2026" description="v2.1.0" tags="v2.1.0, feature">
    Shipped full-screen preview with mobile and tablet views.
  </Update>

  <Update label="April 1, 2026" description="v2.0.0" tags="v2.0.0, breaking, new">
    Complete platform rewrite. See the migration guide for breaking changes.
  </Update>
</Changelog>

Preview:

Update (one per release)

Each <Update> is a single release entry. The component automatically renders the version, date, tags, and author — you only write the body.

Attributes:

MDX:

<Update
  label="April 15, 2026"
  description="v2.1.0"
  tags="v2.1.0, feature, enhancement"
  author="kbayero"
  href="https://github.com/acme/repo/releases/tag/v2.1.0"
  id="v2-1-0"
>
We're thrilled to announce the latest version. Here's what's new:

- Full-screen preview with mobile, tablet, and desktop modes
- In-editor AI assistant accessible with **Cmd/Ctrl + J**
- Drag-and-drop reordering for sections and pages
</Update>

Preview:

Enriching your updates

The body of an <Update> is a regular MDX block — you can drop any of the standard components inside. Images, <Label> badges, <RightPanel> sidebars, callouts, tables, and code blocks all work the same way they do anywhere else.