What format do the messages follow?

They follow the Conventional Commits 1.0.0 format: a type, an optional scope in parentheses, an optional exclamation mark for breaking changes, then a colon and a short description — for example feat(auth): add multi-factor login.

Which commit types are used?

The common Conventional Commits types: feat, fix, chore, docs, refactor, test, style, perf, build, and ci. Each type draws from descriptions that make sense for that category of change.

Why do some messages have an exclamation mark?

An exclamation mark after the type or scope marks a breaking change, per the spec. The generator adds it occasionally to feat and refactor commits so your changelog tooling can be tested against breaking-change detection.

Can these be used to test a changelog generator?

Yes. Because they follow Conventional Commits, tools like standard-version or release-please will group them by type and pick up the breaking-change markers, making them ideal fixtures for changelog testing.

Does anything leave my browser?

No. All messages are generated locally with no network calls, so nothing is sent anywhere.

What is the Random Git Commit Message Generator?

Generate fake git commit messages in Conventional Commits format with types like feat, fix, chore, docs, and refactor, optional scopes, and occasional breaking-change markers. Useful for seeding demo git history and testing changelog generators. It runs free in your browser on Gera Tools, with nothing uploaded.

Random Git Commit Message Generator

Name: Random Git Commit Message Generator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

A random git commit message generator produces fake commit subjects that follow the Conventional Commits format, so you can seed a demo repository’s history or feed realistic input to a changelog generator. It is built for developers testing release tooling and anyone needing plausible commit lines for a demo.

How it works

Each message is assembled to match the Conventional Commits 1.0.0 specification:

A type is chosen from the standard set — feat, fix, chore, docs, refactor, test, style, perf, build, ci.
An optional scope (such as auth, api, or parser) is added in parentheses, or omitted.
For feat and refactor, a breaking-change marker (!) is occasionally inserted after the type or scope.
A description is selected from a pool that fits the chosen type, so a fix reads like a bug fix and a docs reads like a documentation change.

The result is type(scope)!: description, exactly the shape changelog tools expect.

What each commit type represents

Understanding the type taxonomy helps you know what to look for when testing a changelog generator:

Type	What it signals	Changelog section
`feat`	New feature	Features
`fix`	Bug fix	Bug Fixes
`docs`	Documentation only	(often omitted)
`refactor`	Code restructure, no behavior change	(often omitted)
`perf`	Performance improvement	Performance
`test`	Adding or fixing tests	(often omitted)
`chore`	Build, tooling, maintenance	(often omitted)
`ci`	CI/CD pipeline changes	(often omitted)

Breaking changes (marked with !) typically get their own section regardless of type.

Typical output and testing workflow

feat(auth): add multi-factor login
fix(parser): handle null response from upstream
refactor(core)!: split god object into modules
docs: clarify installation steps
chore(deps): bump typescript to 5.4

A practical testing workflow: generate a batch of 20 messages, create a temporary git repository, commit them with git commit --allow-empty -m "..." for each line, then run your release tool against the repo. You can verify that feat and fix appear in the right sections, that the ! triggers a breaking change note, and that chore and docs are correctly suppressed (or included) based on your config.

Tips

The breaking-change ! lets you test breaking-change detection without hand-crafting commits.
Omitting the scope part of some messages tests that your tooling handles both feat: ... and feat(scope): ... forms.
Everything runs locally with no network access — nothing leaves your device.