Are the commit hashes real?

No. They are 40-character hexadecimal strings produced by a seeded random generator. They look like real SHA-1 hashes but are not derived from any actual commit content.

What commit message style is used?

Conventional Commits, like feat(api): add pagination or fix: handle empty input. Types include feat, fix, chore, docs, refactor, test, perf, and style, with optional scopes.

How are the dates assigned?

Commits walk backwards from the current time, with each commit stepping back a random 1 hour to 3 days. This produces a believable descending chronology, just like a real git log.

What is this useful for?

Generating fixtures and demo data for changelog generators, git-history visualizers, release-note tools, and screenshots where you need realistic but non-sensitive commit data.

What is the Fake Git Commit History Generator?

Generates fake git commit history with 40-character hashes, authors, walking-back dates, and Conventional Commits messages. Choose full git log or oneline format. Reproducible from a seed, all in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Fake Git Commit History Generator

Name: Fake Git Commit History 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.

Realistic git history without a repo

When you are building or demoing a changelog generator, a commit-graph visualizer, or release tooling, you need realistic git log output, but you do not want to expose a real repository. This tool synthesizes a believable commit history with proper hashes, authors, dates, and Conventional Commits messages, all generated locally.

How it works

A seed drives a mulberry32 pseudo-random generator so the same inputs always produce the same log.

Hashes are 40 hex characters, matching SHA-1 length. The oneline format shows the first 7, as git does by default.
Messages follow Conventional Commits: a type, optional (scope), then a colon and subject.
Dates start at “now” and step backwards a random interval per commit, so the history reads newest-first like real git log.

Full format looks like:

commit 3f9a2c...e1
Author: Alex Rivera <[email protected]>
Date:   Fri, 06 Jun 2026 10:12:00 GMT

    feat(api): add pagination to list endpoint

Conventional Commits in the output

The generated messages follow the Conventional Commits specification, which is the most common structured commit format in open-source projects. Each message has:

A type such as feat, fix, chore, docs, refactor, test, perf, or style.
An optional scope in parentheses describing which area of the codebase changed, such as (api), (auth), or (ui).
A subject — a short imperative description of the change.

This makes the generated log usable for testing changelog generators that parse this spec to sort commits into release notes, as well as tools like semantic-release that derive version bumps from commit types.

Format comparison

Format	Best for
Full `git log`	Parsing author/date fields; testing log viewers
`--oneline`	Compact changelog screenshots; git graph renderers

The oneline format abbreviates hashes to 7 characters (the git default) and omits author/date, matching what developers see when they run git log --oneline locally.

Use cases

Changelog generators: verify your parser handles all Conventional Commits types, scopes with slashes, and subjects containing colons.
Git graph visualizers: feed a 50-commit history into your renderer and test branching layouts.
Release tooling demos: show a realistic log in a product walkthrough without exposing real commit messages from private work.
Stress testing: crank the count to 200 to verify your virtual-scroll or pagination handles long histories without janking.

Tips and notes

Use the oneline format when you need a compact list for a changelog screenshot, and the full format when your tool parses author and date fields. Increase the commit count to stress-test rendering. Because everything is seeded, you can reproduce the exact same dataset in a test by reusing the seed. Pair a fixed seed with a count to make fixture files deterministic across CI runs.