Skip to main content
Back to Dev generators

Dev

Dummy Git Commit Message Generator

A sparse commit history on a portfolio project or tutorial repository raises immediate doubts. A dummy git commit message generator lets you scaffold a believable log without hand-crafting dozens of messages or exposing commits from a real codebase. Three inputs control the output. Count sets how many messages to generate (1–50). Style picks the format: conventional uses typed prefixes like feat(auth):, fix(cache):, and chore(deps): — ideal for commitlint demos; casual produces natural-language one-liners like 'cleaned up unused imports'; verbose prepends a capitalized action word like 'Implemented' or 'Refactored' for a formal tone. Include Commit Hash controls whether a 7-character random hex prefix appears before each line, along with a date from the past 90 days. Note: commit hashes are randomly generated hex strings with no cryptographic relationship to any real git object.

Read the complete guide — 4 min read

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Set the count field to the number of commit messages you need, between 1 and 50.
  2. Choose a commit style: conventional for typed prefixes, casual for plain messages, or verbose for commits with a body.
  3. Toggle the include hash option to show or hide the short SHA prefix on each line.
  4. Click Generate to produce the commit history, then review the output for a mix you are happy with.
  5. Copy the full block or individual lines and paste them into your demo repo script, slide, or documentation.

Use Cases

  • Populating a portfolio GitHub repo with a realistic-looking conventional commit history
  • Recording a git workflow screencast without exposing real project commits
  • Testing a semantic-release or conventional-changelog pipeline with typed commit prefixes
  • Building a demo git repository using git commit --allow-empty in a shell script loop
  • Creating slide-deck screenshots that show a believable feature branch and fix log

Tips

  • Generate two separate batches — one conventional, one casual — then manually interleave them to avoid a suspiciously uniform log.
  • If screenshotting, generate exactly 8 to 12 commits so the full list fits in one terminal window without scrolling.
  • Turn hashes off when using messages as raw git commit -m input; turn them on for terminal screenshot realism.
  • Edit only the scope token in conventional commits (the word in parentheses) to instantly tailor messages to your project's domain.
  • Use the verbose style when demonstrating git log --stat or GitHub's commit detail view, where a body paragraph looks expected.
  • For changelog tool demos, generate 20 or more commits so the resulting changelog has multiple sections — fixes, features, and chores.

FAQ

how do I make generated commits look like they belong to my project

Generate a batch, then edit the scope tokens in conventional-style messages — swap (api) for (checkout) or (auth) for (payments) to match your domain. The action verbs and structure are already realistic, so small scope edits usually make the log feel project-specific without rewriting every line.

are the commit hashes real git SHA values

No. They are randomly generated 7-character hex strings that mimic the short SHA git displays in git log --oneline output. They have no cryptographic link to any real commit object, so do not use them in scripts that query an actual repository.

what is the difference between conventional, casual, and verbose commit styles

Conventional uses typed prefixes like feat, fix, and chore with a scope in parentheses — ideal for commitlint or changelog tooling demos. Casual produces natural-language messages without prefixes, closer to how many solo developers actually commit. Verbose prepends a capitalized action word like 'Implemented' or 'Consolidated' for a more formal tone.

can I use the generated messages to actually create git commits

Yes. Pipe generated messages into git commit --allow-empty -m "<message>" in a shell script to build a realistic-looking history on an empty repo. Turn off the hash option since git generates its own SHA. This is a common approach for building demo repositories or screencasting without exposing real project work.

You might also like

Popular tools from other categories that share themes with this one.

Try these next

More free tools from other corners of the catalog, picked by shared themes.