AI Git Commit & PR Generator
Paste your git diff or git diff --cached output from the terminal; it analyzes the changed files, line differences and code context to create a compliant Conventional Commits message and a review-ready GitHub Pull Request (PR) draft.
A Guide to Conventional Commits and Modern Git Workflows
Git commit messages and Pull Request (PR) descriptions are the living documentation of a software project. This tool parses the git diff output from your terminal, automatically infers the feat, fix, refactor, perf, docs, test and chore types, sets the module scope from the changed directory structure and creates a PR draft that follows GitHub conventions.
1. What Is the Conventional Commits 1.0.0 Standard?
Conventional Commits is a lightweight set of rules for structuring commit messages. It defines a clear syntax that humans can read easily and automation tools (CI/CD, Semantic Release, Lerna, Changesets) can interpret without errors:
<type>[optional scope][!]: <short description>
[optional body / statistics]
[optional footer: BREAKING CHANGE or issue reference]If a change breaks backward compatibility (a breaking change), a ! is added right after the type or scope (e.g. feat(api)!: migrate to v2 auth format) or BREAKING CHANGE: description is written in the footer. SemVer automation tools then bump the version as a Major release automatically.
2. Supported Commit Types and How to Use Them
Choosing the right commit type speeds up code reviews within the team and makes changelogs crystal clear:
| Type | SemVer Impact | When to Use It? | Example |
|---|---|---|---|
| feat | MINOR (0.X.0) | When a new feature is added for users or API consumers. | feat(auth): google oauth support |
| fix | PATCH (0.0.X) | When a bug, a crash-causing defect or unexpected behavior is fixed. | fix(cart): cart total decimal bug |
| refactor | PATCH / None | Cleanup, renaming or architectural changes that do not change code behavior. | refactor(db): optimize prisma client queries |
| perf | PATCH | Optimizations that improve the app's runtime, memory or network usage. | perf(images): switch to avif and lazy-load |
| test | None | When missing unit/e2e tests are written or broken test scenarios are fixed. | test(checkout): payment flow playwright tests |
| docs | None | When only the README, wiki or in-code documentation is updated. | docs(readme): add pnpm to setup steps |
| chore | None | Dependency updates, tsconfig, package.json or linter settings. | chore(deps): upgrade to next.js v15 |
3. Quickly Getting a Git Diff from the Terminal and Copying It to the Clipboard
Handy diff commands you can use in the terminal for different situations:
git diffgit add) (Recommended):git diff --cached(or git diff --staged)git diff HEAD~1git diff --cached | pbcopygit diff --cached | xclip -sel clipgit diff --cached | Set-Clipboard4. How to Prepare a High-Quality GitHub / GitLab Pull Request
A good PR lets reviewers understand what changed and why without wasting time:
- Keep It Small and Focused: Open atomic PRs that solve a single responsibility instead of huge 500+ line PRs.
- Add a Verification / Test Plan: Like the template this tool produces, state clearly how the reviewer can test the code locally or in a preview environment.
- Link the Related Issue: Write
Closes #123orFixes PROJ-42in the PR body so the issue closes automatically when the PR is merged.
5. Zero Data Transfer: Fully Client-Side Privacy
In enterprise projects and private repositories, the biggest concern is code leaking to third-party cloud LLM services. This tool runs the entire analysis locally in your browser's JavaScript engine. No git diff data, tokens or source code is sent to a server; it is secure enough to work fully offline.
More Tools for Your Developer Workflow
Other free tools you may need during development: