Generate CHANGELOG.md from git log
A CHANGELOG.md is the project history from the user's point of view: what they got in 1.2, what is new in 1.3, what breaks in 2.0. The Keep a Changelog format groups changes into "Features", "Bug Fixes", "BREAKING CHANGES" and a few more. Pairs naturally with SemVer.
This tool reads the output of `git log --oneline` (or `git log --pretty=format:"%H %s"` for full hashes) and groups commits by Conventional Commit type. The result: a ready CHANGELOG.md section with commit links, a date, and the version number.
You can hide types that should not be visible to users (docs, chore, ci, ...). You can also paste an existing CHANGELOG.md, the generator inserts the new section at the top, keeping older versions. GitHub links are built from the repo URL you provide.
How to use it
- Generate the commit list in the terminal: `git log --pretty=format:"%H %s" v1.2.0..HEAD` (commits from version v1.2.0 to now). Or `git log --oneline v1.2.0..HEAD`, short hashes, same data.
- Paste the output into the "Input" pane on the left. The generator parses each line: hash + Conventional Commit (type, scope, description, breaking flag).
- Fill in the version metadata: previous (v1.2.0), current (v1.3.0), release date (today by default), repo URL (used to build `commit` links).
- Pick the commit types to include, the chips at the bottom of the panel. Enabled by default: feat, fix, perf, revert (the ones users care about). Disabled: docs, style, refactor, test, build, ci, chore (internal).
- "Append to existing CHANGELOG" mode (Switch), paste the current CHANGELOG.md, the generator inserts the new section above the first `##` (i.e. above the most recent version). The output is a complete file, overwrite the old one.
- Copy or download the file. Drop it into your repo, commit "chore(release): v1.3.0", push, tag, publish.
When this is useful
Concrete situations where a changelog generator shortens the release:
- An npm / PyPI / cargo release. Before publishing you want a "What's new in 1.3.0" section in the README or in the GitHub Release description. Paste the commits since the last tag, get a ready section.
- GitHub Release notes. After pushing a tag, GitHub asks "Generate release notes". Paste the section generated here into "describe this release", it looks professional and the commits are clickable.
- Customer-facing docs. The customer wants to know what shipped in the sprint. Pull `git log v1.2.0..HEAD`, generate a changelog, email it or paste it into Confluence. Every commit linked, clean groups.
- A replacement for `semantic-release` in projects where the automation is overkill. For a small project that releases once every two months, generating manually here is faster than configuring a full auto-release pipeline.
- A historical audit. Want to see exactly what changed between two year-old versions? Paste the output of `git log v0.5.0..v0.7.0`, generate the changelog, you get a full summary.
- Onboarding new teammates. "What happened in the project over the last year?", a generated 12-month changelog gives the full picture.
If your commits are not Conventional Commits yet, use our commit builder so new commits land in the right shape. And if you want to link the changelog from a README, the README builder has a "Changelog" section ready to go.