A changelog generator needs a commit history to parse, and writing forty conventional commits by hand is tedious. These come with correct type, scope and breaking-change markers, plus the hashes and stats a log view needs.
What you can control
- Conventional Commits with proper type, optional scope, and the
!breaking-change marker. - Full 40-character hashes plus the 7-character short form, both from the same value.
- Branch names derive from the commit subject, matching the convention most teams follow.
- Diff statistics — files, insertions, deletions — for testing a commit list or a contribution graph.
What this is not
Hashes are random hex rather than real SHA-1 digests of any tree. They have the right shape and will not match anything in a real repository.
Questions
What is Conventional Commits?
A message convention: a type, an optional scope, then a description — fix(auth): handle expired token. It lets tooling derive version bumps and changelogs automatically.
Why does a breaking change use an exclamation mark?
feat!: or feat(api)!: signals a major version bump. The alternative is a BREAKING CHANGE: footer in the body, which the body option here produces.
Are the hashes real SHA-1 values?
No. They are 40 random hex characters — the right shape, but not a digest of any actual commit object.