Changelog Generator
Paste your commit messages or a list of changes and get a structured changelog entry. Lines are sorted by type, merge commits and internal chores are filtered out, breaking changes are highlighted, and the next version number is suggested according to semantic versioning.
- Runs in your browser
- No sign-up
- Free to use
How to use Changelog Generator
- Paste commit messages, one per line, for example from git log --oneline.
- Enter the previous version; the new version is suggested, or type your own.
- Choose the format and add the repository URL if you want links.
- Review the wording, then copy the entry into CHANGELOG.md or your release.
Changelog Generator features
Understands conventional commits
feat, fix, perf, refactor, docs, security and others are mapped to changelog sections.
Breaking changes surfaced
Commits marked with ! or BREAKING CHANGE are listed first, in their own section.
Version suggestion
Major for breaking changes, minor for features, patch for fixes, with the pre-1.0 rule applied.
Noise removed
Merge commits are skipped, and chore, ci, test, build and style commits are left out unless you ask for them.
Links
Commit hashes, pull request numbers and a compare link are turned into links when a repository URL is given.
Three formats
Keep a Changelog, GitHub release notes, or plain text.
When to use Changelog Generator
- Writing the changelog entry for a new release.
- Drafting release notes for a GitHub or GitLab release.
- Summarising a sprint or a deployment for the team.
- Deciding the next version number from what changed.
Changelog Generator FAQ
Which commit format is recognised?
The Conventional Commits pattern: a type, an optional scope in brackets, an optional exclamation mark for breaking changes, a colon and a description, as in “fix(login): redirect after sign-in”. Lines that do not follow it are kept and listed under “Other”.
How do I get the commit list?
Run git log --oneline followed by the range, for example git log --oneline v1.3.0..HEAD for everything since the tag v1.3.0. Copy the output and paste it in. Each line starts with the short hash, which the tool recognises.
How is the next version chosen?
By semantic versioning. A breaking change raises the major number, a new feature the minor number, and anything else the patch number. For versions below 1.0.0, breaking changes raise the minor number, as is conventional while an API is still unstable. You can always type a version of your own.
Should every commit appear in a changelog?
No. A changelog is written for users of the software, a commit log for its developers. Refactorings, test changes and dependency bumps rarely matter to users. The generator hides those types by default, and the remaining lines are worth rewording from the user's point of view.
What is Keep a Changelog?
A widely used convention for CHANGELOG.md files: newest version first, a date for each release, and changes grouped under Added, Changed, Deprecated, Removed, Fixed and Security. It is designed to be read by people and is easy for tools to parse.
Is my commit history uploaded?
No. The text is processed in your browser only.
A changelog is for people
A changelog answers one question for someone deciding whether to upgrade: what is different, and does it affect me? A raw list of commits answers a different question, namely what the developers did, and contains merges, typo fixes and internal restructuring that a user neither needs nor understands. Turning the second into the first is mostly a matter of selecting, grouping and rewording.
Grouping by kind of change makes an entry scannable. A user who only cares about security fixes can jump to that heading. Breaking changes deserve the most prominent place, because they are the items that require action. The Keep a Changelog convention fixes a small set of section names so that every project's changelog reads the same way, and it puts the newest release at the top with its date.
Automation works when commit messages carry structure, which is the purpose of the Conventional Commits convention. A prefix states the kind of change, an optional scope names the affected area, and an exclamation mark flags an incompatible change. With that in place, tools can sort commits into sections and derive the next version number: breaking changes mean a new major version, features a new minor version, fixes a patch. The number then tells users how cautious to be before they even read the list.
Generated output is a draft. Commit messages are written in the moment, for colleagues, and often describe the implementation rather than the effect. “Cache the dashboard query” becomes more useful as “The dashboard loads faster”. Spend a few minutes editing the lines into statements about what users will notice, and the changelog becomes something people read with trust.