- What are Conventional Commits and why use the format?
- Conventional Commits is a lightweight convention for commit messages — every commit starts with a type (feat, fix, refactor, etc.), an optional scope in parentheses, a colon, and a short summary. The structure makes commits machine-readable: tools like semantic-release can auto-bump version numbers and generate changelogs by reading the type. Even if you don't use those tools, the format keeps your commit log scannable. The full spec lives at conventionalcommits.org.
- What's the 50/72 rule?
- A long-standing Git convention from the days of email-driven kernel development: the subject line should be ≤50 characters, then a blank line, then the body wrapped at ≤72 characters per line. The numbers come from the 80-column terminal of the time — Git's tools (`git log --oneline`, `git log --pretty=format`, `git format-patch`) still assume the limits, and Linus Torvalds enforces something close to it in the Linux kernel. The generator flags any subject ≥51 chars and wraps body lines at 72 automatically.
- Which commit types should I use?
- The eleven types in this generator are the spec's recommended set: `feat` (a new feature), `fix` (a bug fix), `refactor` (code change that doesn't fix a bug or add a feature), `docs` (docs only), `style` (formatting, whitespace), `perf` (performance), `test` (tests), `chore` (deps, tooling), `build` (build system), `ci` (CI config), `revert` (reverts a previous commit). Some teams add `wip` or `release` — the spec doesn't lock the list, but these eleven cover ~95% of cases.
- How does the breaking-change marker work?
- Filling the breaking-change field does two things: it adds a `!` after the type and scope (so `feat(api)!: change response shape`), and it appends a `BREAKING CHANGE:` footer with your description. Tools like semantic-release read the `!` or the footer and bump the major version (1.x.y → 2.0.0). If both are present they convey the same thing — semantic-release is happy with either.
- Should the summary be in imperative present tense?
- Yes — that's the convention every major project (Linux, Git itself, Angular, Vue, Rails) follows. Write `add login redirect` not `added login redirect` or `adds login redirect`. The mnemonic from the Git docs: the commit message should complete the sentence "If applied, this commit will __." If you can drop your summary in there and it reads naturally, you're using the right tense.
- What goes in the body vs the summary?
- The summary answers *what* changed in one line. The body answers *why* — the tradeoffs, the alternatives you considered, the context a reviewer needs. If your change is obvious (`fix typo in README`), skip the body. If it's not (`fix: cache invalidation on logout`), the body is where you explain that you can't invalidate on the session-token TTL because that breaks SSO. Six months from now, that's the paragraph you'll thank yourself for.
- How do I link to issues or PRs?
- Type them into the Issue refs field — `#123`, `123` (we'll add the hash), or external tracker IDs like `JIRA-7`. The generator normalizes the list and emits a `Refs:` footer. GitHub, GitLab, Bitbucket, and most Jira integrations auto-link bare `#123` references in the commit body when the commit lands in a repo connected to the tracker. For closes-this-issue semantics, write `Closes #123` or `Fixes #123` directly in the body — GitHub treats those as auto-close keywords.
- Does the generator validate or just format?
- Both. It validates the type against the allowed list, checks the scope shape (lowercase letters, digits, dashes, slashes — common conventions), warns when the summary is over 50 characters, and warns when a body line was longer than 72 (and wrapped automatically). It never *blocks* the output — you always get the message, you just get a heads-up about what's not pristine. Some teams have stricter rules (commitlint, husky) — for those, treat this tool as a draft step.
- Why is there no AI in this tool?
- Generating a commit message from a diff is one thing — choosing the type, deciding the scope, writing a summary that conveys intent — but *formatting* one is deterministic. The 50/72 rule, the type prefix, the breaking-change footer, the refs trailer: all of that is mechanical. Putting an LLM in the path would just be a slower, more expensive way to do string concatenation. This is the formatter; the writing is still yours.
- Does it leave my commit text on a server somewhere?
- No. The whole tool is JavaScript that runs in your browser tab. The summary, the body, the scope, the refs — none of it leaves the page, isn't logged, isn't stored. Useful when your commit body quotes internal table names, ticket links, customer identifiers, or anything you'd rather not paste into someone else's server.
