Paste your commit messages, for example the output of git log --oneline --decorate, and get a tidy CHANGELOG.md. Conventional Commit types are sorted into Added, Changed, Fixed and the other Keep a Changelog sections, tags become versions, and the next semantic version is suggested for unreleased work.
Last updated:
Tip: paste the output of git log --oneline --decorate (tags become versions) or git log --format="%h %ad %d %s" --date=short to include dates.
Advertisement
Advertisement
How to use the Changelog Generator
Get your commits: run git log --oneline --decorate (or with --format="%h %ad %d %s" --date=short for dates) and copy the lines since the last release.
Paste them into the left box, newest first, as git prints them. A sample loads to start.
Pick the format: Keep a Changelog or Conventional, and decide whether maintenance and non-conventional commits are included.
Check the version: accept the suggested semver bump, type your own, or keep new commits under Unreleased.
Add your repository URL for clickable commit and compare links, then copy or download CHANGELOG.md.
Conventional Commit types and where they go
Commit
Keep a Changelog section
Conventional section
Version bump
feat: add CSV export
Added
Features
Minor
fix: handle empty input
Fixed
Bug Fixes
Patch
fix(deps): patch CVE-2024-1234
Security
Bug Fixes
Patch
perf: cache parsed queries
Changed
Performance Improvements
Patch
refactor: split scheduler
Changed
Code Refactoring
Patch
feat: deprecate /v1/reports
Deprecated
Features
Minor
feat!: remove v1 endpoints
Removed (marked BREAKING)
Features + ⚠ Breaking Changes
Major
docs, chore, ci, test, build, style
Changed (only if included)
Their own sections (only if included)
Patch
Update README (not conventional)
Changed (if included)
Other Changes (if included)
Patch
Getting the right commits out of git
git log --oneline --decorate prints one line per commit with tags such as (tag: v1.4.0), which become version headings.
git log --format="%h %ad %d %s" --date=short adds the commit date, used as the release date of each tagged version.
git log v1.4.0..HEAD --oneline lists only the commits since the last release, ideal for writing the next section.
git log --no-merges leaves out merge commits up front (the generator skips them anyway).
Writing a changelog people actually read
Write commit subjects in the imperative mood ("add", "fix", "remove") and describe the effect for users, not the code change.
Edit the generated text before publishing: merge related entries, drop internal details and add migration steps for breaking changes.
Keep the newest release at the top and date every version in ISO format (YYYY-MM-DD) so the order is unambiguous worldwide.
Collect upcoming work under Unreleased and rename it to the version number when you tag the release.
Frequently asked questions
What input does the changelog generator expect?
One commit subject per line, newest first, exactly as git log prints it. A short or full hash at the start of the line is detected, as are dates in YYYY-MM-DD format and tag decorations such as (tag: v1.4.0). Indented lines after a commit are treated as its body, so a BREAKING CHANGE: footer is picked up. A line that is only a version, such as v1.4.0 or ## 1.4.0, starts a new version too.
How are Conventional Commit types mapped to Keep a Changelog sections?
feat goes to Added, fix to Fixed, and perf, refactor, revert and other types to Changed. Commits whose description starts with deprecate go to Deprecated, ones that start with remove or drop go to Removed, and fixes that mention security, a CVE or a vulnerability go to Security. Breaking changes are marked BREAKING in their section.
How is the next version number chosen?
It follows Semantic Versioning from the newest tag in your list: any breaking change bumps the major version, otherwise any feat bumps the minor version, otherwise the patch version goes up. Before 1.0.0, a breaking change bumps the minor version instead, which is a common convention for initial development. You can always type your own version.
Why are some commits missing from the changelog?
Merge commits are always skipped because they repeat the work of other commits. Commits typed docs, chore, ci, test, build or style are hidden by default because users rarely care about them; tick the option to include them. Breaking changes are always shown, whatever their type.
What is Keep a Changelog?
Keep a Changelog is a widely used convention for human-readable changelogs: the newest version first, one heading per release with its date, changes grouped under Added, Changed, Deprecated, Removed, Fixed and Security, and an Unreleased section for upcoming work. It pairs naturally with Semantic Versioning.
Does it work with GitLab and GitHub links?
Yes. Enter the repository URL and the generator links commit hashes, #123 issue references and version compare views using GitHub or GitLab URL patterns, detected from the address. Without a URL the changelog stays plain text.
Are my commit messages sent anywhere?
No. Parsing and formatting happen in your browser, so private repository history stays on your device.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.