How to use the changelog from commits generator
- Paste your commit messages, one per line. Lines like feat(scope): add a thing or fix: correct a bug are read as conventional commits, and a commit hash at the start of a line is ignored.
- Enter the current version as three numbers, such as 1.4.2. Add a release date if you want one in the heading.
- Choose whether to list lines that are not in the conventional format under Other changes.
- Copy the Markdown or download it, and use the suggested version number for the release.
Conventional commits to release notes
The conventional commits style puts a type at the start of each commit message: feat for a new feature, fix for a bug fix, perf for a speed improvement, and others such as docs, chore and refactor. A scope in parentheses names the area, and an exclamation mark before the colon, or a line starting with BREAKING CHANGE, marks a change that breaks existing users.
The sample has seven conventional lines and one merge line. The tool groups them under Breaking changes first, then Features, Bug fixes, Performance, Documentation and Chores, and puts the merge line under Other changes. Scopes appear in bold before the text, such as parser: support nested lists.
Suggesting the next version
Under semantic versioning, a breaking change raises the first number, a new feature raises the middle number and a fix raises the last number. The tool applies that rule to the commits you paste: any breaking change is a major bump, otherwise any feature is a minor bump, otherwise a fix or a performance change is a patch bump. The sample has a breaking change, so 1.4.2 becomes 2.0.0.
If the commits hold only documentation or chores, the tool says no bump is needed and keeps the version. This is a suggestion that follows a common convention. Projects set their own rules, for example for versions below 1.0, so check yours. The Semantic Version Comparator compares two versions, and the README Generator helps write the rest of your project docs.
Limits and privacy
The tool reads text only. It does not connect to a repository, so copy messages from your own history, for example with a log command that prints one line per commit. Lines are limited to 5,000, and a commit with a long body needs only its first line.
Your messages stay in the page and are not uploaded or stored. Review the generated text before you publish it, because commit messages are written for developers and often need editing for readers. Use the Diff Checker to compare two versions of a changelog, and the JSON Formatter and Validator for package files.
Assumptions and limits
- Commit lines follow the form type(scope)!: description, with an optional leading hash and bullet.
- A line starting with BREAKING CHANGE: applies to the commit above it and adds a note to the entry.
- The suggested version follows the usual semantic versioning rule and does not know your project's own rules.
- Everything is generated in your browser from the text you paste.
Frequently asked questions
What is a conventional commit?
It is a commit message that starts with a type, an optional scope and a colon, such as fix(api): handle empty input. The structure lets tools group changes and decide a version number automatically.
How does it choose the next version?
A breaking change makes it a major bump, a feature a minor bump, and a fix or a performance change a patch bump. Other types alone do not call for a new version.
What happens to lines that are not conventional?
They are not grouped. If you keep the option on, they are listed under Other changes so you can edit them. A note tells you how many there were.
Can I include a commit hash at the start of each line?
Yes. A hash of 7 to 40 hexadecimal characters followed by a space is removed before the line is read, so output from a one-line log works as it is.