Commit Conventions That Scale Down to a Team of One

Commit conventions are usually justified by what they do for a team: a consistent git log that a reviewer or a future teammate can scan. dev-hub has exactly one committer, and the convention stayed anyway — [Type] Brief description, title case, no body unless strictly necessary, no Co-Authored-By line.

Who the format is actually for

It turns out the primary reader of git log on a solo project is the same person, months later, who has fully forgotten the context. [Backend] Add Weekly PageView Retention Cleanup Job is scannable in a way that a vague "fix stuff" or an over-long paragraph explaining every implementation detail isn't — the tag alone answers "do I need to look at this" before the description is even read.

Why "no body unless strictly necessary" is the harder rule to keep

The tempting failure mode on a solo project is the opposite of a lazy commit message — it's an essay, because there's no reviewer to keep concise for and the temptation is to over-explain to future-self. The discipline is realizing that the code diff is the explanation; the commit message's job is only to say what changed and why it was worth a separate commit, which a well-chosen [Type] and a few words already does.

What no Co-Authored-By signals

An AI agent does a large share of the typing on this project, and the commit history still doesn't attribute lines to it. That's a deliberate call about what the git history is for — a record of what changed and why, not a record of which tool held the keyboard. The decision of what ships is the human's, made explicit by the rule that commits only get created "with explicit user permission" regardless of who drafted them.