Generate Conventional Commit messages from git diff — auto-detect type, scope, and breaking changes
git diff or git diff --staged in your terminal), or simply type a brief natural-language description of your changes. The tool analyzes the content to intelligently suggest the appropriate commit components: the type (feat, fix, docs, style, refactor, perf, test, chore, ci, build), the optional scope (the affected module or component — e.g., auth, api, ui, db), and whether the change introduces a breaking change (signaled by ! after the type/scope and a BREAKING CHANGE: footer).feat(api): add user authentication endpoint) ideal for quick commits and GitHub PR titles; Standard — a structured format with type, scope, subject line, and body paragraph generated from the diff summary; Detailed — a comprehensive format including type, scope, subject, multi-paragraph body, breaking change footer if applicable, and references section — ideal for significant features and public repositories.git commit -m or your Git client. Using Conventional Commits consistently provides immediate benefits: automated semantic versioning (fix → patch bump, feat → minor bump, BREAKING CHANGE → major bump), automated CHANGELOG.md generation via tools like standard-version or semantic-release, clearer git history for code reviews (you can scan commit types to understand the nature of each change), and easier onboarding — the structured format eliminates the 'what message should I write?' hesitation. All analysis happens locally in your browser — your code diffs, which may contain proprietary business logic, never leave your device.Conventional Commits (<a href="https://www.conventionalcommits.org">conventionalcommits.org</a>) is a lightweight convention on top of Git commit messages, originally inspired by the Angular commit guidelines. A compliant message has the structure: <code><type>[optional scope]: <description></code>, optionally followed by a body and footer(s). The standard types are: <strong>feat</strong> — a new feature (triggers a MINOR version bump in semver); <strong>fix</strong> — a bug fix (triggers a PATCH bump); <strong>docs</strong> — documentation changes; <strong>style</strong> — formatting changes (not affecting code logic); <strong>refactor</strong> — code restructuring without feature changes or bug fixes; <strong>perf</strong> — performance improvements; <strong>test</strong> — adding or correcting tests; <strong>chore</strong> — maintenance tasks (dependency updates, build config); <strong>ci</strong> — CI/CD changes; and <strong>build</strong> — build system changes. A <code>!</code> after the type/scope (e.g., <code>feat!</code> or <code>feat(api)!</code>) indicates a BREAKING CHANGE, triggering a MAJOR version bump. The specification became the industry standard because it enables full automation of the release pipeline — semantic-release, standard-version, and similar tools parse Conventional Commit history to determine the next version number, generate changelogs, and publish releases with zero human intervention.
The auto-detection uses heuristic analysis of the diff content to suggest commit components. <strong>Type detection</strong>: the tool scans for keywords and patterns — additions of new functions/classes/endpoints suggest <code>feat</code>; changes to error handling, null checks, or boundary conditions suggest <code>fix</code>; pure formatting changes (indentation, whitespace) suggest <code>style</code>; changes only to test files suggest <code>test</code>; changes to README, comments, or docstrings suggest <code>docs</code>. <strong>Scope detection</strong>: the tool extracts file paths from the diff and identifies common directory patterns — <code>src/auth/</code> suggests scope <code>auth</code>, <code>src/components/</code> suggests <code>ui</code>. <strong>Breaking change detection</strong>: the diff is scanned for signatures of breaking changes — modified function signatures (parameter changes), removed exports, changed API response schemas, and explicit 'BREAKING CHANGE' or 'deprecated' comments. The detection is heuristic, not semantic — it doesn't understand your code's meaning, only its structural patterns. Always review suggestions before committing; the manual override options let you correct any misdetections. Like all PivaBox, processing happens locally in your browser.
The tool generates messages following the standard Conventional Commits specification, which is designed to be extensible. For team-specific requirements, you can customize the output: (1) <strong>Jira/issue tracker references</strong> — add ticket numbers manually to the generated message body or footer (e.g., <code>Refs: PROJ-1234</code>), or include them in the scope field (<code>feat(PROJ-1234): add export feature</code>). (2) <strong>Custom types</strong> — while the dropdown shows the standard Conventional Commits types, you can type any custom type in the scope field or edit the generated message text directly. (3) <strong>Co-authored-by trailers</strong> — add <code>Co-authored-by: name <email></code> footers manually after generation. (4) <strong>Team-specific prefixes</strong> — some teams use emoji prefixes or custom type labels; you can add these in the message body after generation. For fully automated customization (always including Jira ticket from branch name, always adding specific trailers), integrate commit message generation into your Git hooks (<code>prepare-commit-msg</code> hook) or use commitizen (cz-cli) with a custom adapter. The PivaBox generator serves as a quick, private, browser-based alternative for crafting well-structured commit messages, particularly useful for developers who don't have a full commit toolchain configured.