How to Write Better Git Commit Messages with AI (2026)

How do you write better Git commit messages with AI in 2026? Stage one logical change, generate a draft from the staged diff using a tool that supports Conventional Commits, then edit the draft so the subject states user-visible intent in imperative mood — for example, fix(auth): expire refresh tokens on password reset. Keep types consistent (feat, fix, refactor, docs, chore), add a body when the why matters, and never let a model be the final historian of your repository.

Five-step recipe: git add -p → generate (GitHub Copilot sparkle, aicommits --type conventional, or the ILAA Commit Message Generator) → enforce type(scope): subject → add issue ref or BREAKING CHANGE footer → commit after a 10-second human review. The whole loop takes under 30 seconds for a focused change.

Why Commit Quality Still Matters When AI Writes the Code

It is tempting to think that if AI is writing the code, commit messages matter less. The opposite is true. As AI coding agents and pair-programming tools generate more commits per day, the average signal in each message drops unless you actively maintain quality. More commits with vague messages is worse than fewer commits with clear ones.

Bisect, blame, and onboarding still read messages, not vibes

When production breaks at 2 AM, git bisect walks commit by commit. If each subject is "update stuff" or "AI suggestions", the bisect is useless — you are trading a binary search for a linear scan. A subject like fix(billing): round tax to two decimals before Stripe submission immediately flags itself as a suspect or rules itself out.

git blame is the same story. When a new engineer asks "why does this line exist?", the blame output shows a commit hash and a subject. If the subject explains intent, they have their answer. If it says "refactor", they have to read the diff, guess the motivation, and probably ping you on Slack.

Onboarding moves faster when history is a readable narrative. A well-kept commit log is the cheapest documentation a team can produce — it costs nothing beyond discipline and pays out every time someone opens git log --oneline.

Changelogs, semantic-release, and automated versioning

Conventional Commits is not just a style preference — it is the input format for an entire automation chain. semantic-release reads feat: commits and bumps the minor version. It reads fix: commits and bumps the patch. It reads BREAKING CHANGE footers and bumps the major. Tools like release-please and Changesets do the same.

When commit messages are free-form, this automation breaks. You fall back to manually editing CHANGELOG.md files, which means the changelog is always stale, always incomplete, and always someone's least favorite task. Conventional Commits with AI-assisted drafting gives you the automation for free.

The agent volume problem

AI coding tools like Aider auto-commit after each edit loop. Cursor generates commits in its Source Control panel. Claude Code and similar agent CLIs pipe diffs into models and produce commit messages as a byproduct. This is convenient, but it means a single afternoon of agentic coding can produce 15 commits where a human would have produced 3.

If those 15 commits all have model-generated subjects like "Update user.py, auth.py, and session.py", your repository history degrades rapidly. The fix is not to stop using agents — it is to apply the same commit discipline at agent speed: split logical units, constrain the format, and review the subject before it lands.

What "better" means in 2026

A good commit message in 2026 is four things:

1. Searchable — you can find it later with git log --grep or GitHub search.
2. Conventional — it follows type(scope): description so automation can parse it.
3. Intent-rich — it explains why the change exists, not what files were touched.
4. Reviewable — a teammate can read the subject and body and decide whether the diff makes sense without reading every line.

AI helps with all four when configured correctly. Without configuration, it defaults to file-list summaries — which satisfy none of them.

Conventional Commits in 90 Seconds: The Shared Language for Humans and Models

Conventional Commits is a lightweight specification that sits on top of Git. It gives both humans and models a predictable structure, which means you can constrain AI output to a known format instead of free-associating prose.

Anatomy of a Conventional Commit

type(optional-scope)(optional !): subject

optional body, wrapped at ~72 characters

optional footer(s)

The subject is lowercase after the colon, written in imperative mood ("add", not "added"), with no trailing period, and ideally under 50 characters. The body explains why the change was made — the diff already shows what changed. Footers carry metadata like BREAKING CHANGE:, Closes #123, or Refs: ABC-456.

Types cheatsheet

Imperative mood — bad vs good

The test: if you complete the sentence "If applied, this commit will..." with the subject, it should read naturally. "If applied, this commit will fix(auth): expire refresh tokens on password reset" — yes. "If applied, this commit will fixed stuff" — no.

Body, footers, and BREAKING CHANGE

feat(api)!: rename /v1/tokens to /v1/access-tokens

BREAKING CHANGE: clients must update the path; the old route
returns 410 Gone. Migration guide in docs/migration-v3.md.
Closes #1842

The ! after the scope signals a breaking change at a glance. The BREAKING CHANGE: footer spells out what breaks and what to do. Issue references go in the footer, not the subject.

Why LLMs default to fluff without a format constraint

Ask an unconstrained model to "write a commit message for this diff" and you will usually get something like "Update auth.js, session.js, and token.test.js to handle token expiry". That is a file list dressed as a sentence. It tells you nothing about intent, type, or scope.

Constrain the same model with a system prompt that specifies Conventional Commits, imperative mood, and a 50-character subject, and the output improves dramatically. The format does half the work — the model just fills in the slots.

Where AI Helps vs Where It Fails

Knowing the boundary between high-ROI AI drafts and failure modes keeps you from blindly accepting misleading messages.

High-ROI cases

• Dependency bumps — chore(deps): bump lodash to 4.17.21. The diff is mechanical and the intent is obvious.
• Renames and formatting — style: run prettier across checkout module. No business logic to misinterpret.
• Obvious fixes — null checks, typo corrections, missing imports. The diff and the fix are the same thing.
• Test additions — test(billing): cover VAT rounding edge cases. The test names usually contain the intent.
• Translating messy working commits — if you committed "wip stuff" during a sprint, AI can read the diff and produce a clean conventional subject for an amend.

Failure modes

• Multi-concern diffs. A diff that touches auth, billing, and CI in one commit produces a muddy subject like "update auth, billing config, and CI pipeline". AI cannot untangle this — you need to split the commit.
• Architecture intent. A diff that moves logic from controllers to services may be driven by a design decision only you know. AI sees file moves and describes them, missing the "why."
• Silent behavior changes. A one-line change to a comparison operator might fix a subtle bug or introduce one. AI describes the code it sees, not the behavior shift.
• Security-sensitive wording. A patch for an injection vector should explicitly call out the risk. AI may soften the language to "update input handling" instead of "fix(security): sanitize SQL input in search endpoint".

The mixed-diff trap — why git add -p is still the skill

The single biggest predictor of AI commit quality is diff quality. A focused, single-concern diff produces a focused, single-concern subject. A mixed diff produces mush.

git add -p (patch mode) lets you stage hunks one at a time. If you finished a bug fix and a refactor in the same file, you can stage just the bug-fix hunks, commit, then stage the refactor hunks separately. AI tools can only work with what you give them — staging discipline is the upstream skill that makes every downstream tool better.

If a change set is too large to describe in one sentence, it is too large for one commit. That sentence is your smoke test.

The Daily Workflow: Stage → Draft → Edit → Validate → Ship

This is the core workflow that works regardless of which tool you pick. The tool changes; the discipline does not.

Step 1 — Stage for the model (single purpose)

git add -p

Review each hunk. Stage only the hunks that belong to one logical change. If you find yourself thinking "this is two things," it is two commits. Stage the first set, commit it, then stage the second set.

Exclude secrets, temporary debug code, and anything you do not want in history. git add -p is also your last chance to catch a .env file or a hardcoded API key before it enters the repository.

Step 2 — Generate with constrained format

Run your chosen tool with Conventional Commits enabled:

• Copilot: click the sparkle in the SCM panel (VS Code, GitHub Desktop, or github.com).
• aicommits: aicommits --type conventional
• OpenCommit: oco (configured with conventional format)
• Cursor: "Generate Commit Message" button in Source Control.
• ILAA generator: paste git diff --staged output into the Commit Message Generator.

The model reads the staged diff and returns a draft subject (and optionally a body). This takes 2–5 seconds.

Step 3 — Human edit for why, risk, and tickets

This is the 10-second step that separates good history from noise. Run through this checklist:

1. Intent: Does the subject state the why, not just the what? If it reads like a file list, rewrite it.
2. Type: Is the type correct? A refactor is not a feature. A dependency bump is chore or build, not feat.
3. Scope: Is the scope meaningful? fix(auth) is useful; fix(src) is not.
4. Ticket: Add the issue ref if the model did not pick it up from the branch name.
5. Risk: If the change is breaking, security-sensitive, or affects payments/auth, add a body note. Do not let AI minimize risk.

If the first draft is file-list fluff, use the "why rewrite" second-pass prompt (see the Prompt Templates section below) or just edit it manually. The edit should take under 10 seconds for a focused commit.

Step 4 — Validate (commitlint / husky / CI)

If your team has commitlint configured with husky or lefthook, the hook runs automatically when you commit. It checks:

• Subject matches type(scope): description
• Type is in the allowed list
• Subject is not too long (typically 72–100 chars max)
• Body lines are wrapped at 72 or 100 chars

If the message fails lint, fix and recommit. If you have a genuine emergency and need to bypass, use --no-verify — but document why and amend the message later.

Step 5 — Align PR titles and release notes with the same grammar

When you open a pull request, use the same Conventional Commits format for the PR title. This keeps changelog tools consistent across commits and PRs. Many teams also use AI to draft PR descriptions from the branch's commit log — if every commit on the branch is conventional, the PR summary writes itself.

After merge, tools like AI code reviewers can catch issues that slipped through. Good commits feed clean PRs; clean PRs feed reliable releases.

Pick Your 2026 Stack (Decision Tree)

You do not need to try every tool. Choose based on where you already spend your time and what constraints your team has.

Already in VS Code + GitHub → GitHub Copilot

If your team is standardized on GitHub and VS Code (or GitHub Desktop), Copilot's commit generation is the lowest-friction path. The sparkle icon in the Source Control panel reads your staged diff and produces a subject and body. Copilot-generated commit messages are also available directly on github.com, which became generally available in late 2025.

Add a custom instruction in your VS Code settings to enforce Conventional Commits:

"github.copilot.chat.commitMessageGeneration.instructions": [
  {
    "text": "Use Conventional Commits: type(scope): description. Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore. Imperative mood. Subject under 50 characters. Prefer explaining why over listing files. Add a short body when behavior or risk is non-obvious."
  }
]

This one-time configuration means every future Copilot commit draft follows your format without re-prompting.

Terminal-first / multi-provider → aicommits

aicommits is a CLI tool that reads your staged diff, sends it to an LLM, and returns a suggested message. It supports multiple providers — TogetherAI, OpenAI, Groq, xAI, OpenRouter, Ollama, LM Studio, and any OpenAI-compatible endpoint — so you can switch models without switching tools.

npm install -g aicommits
aicommits setup          # pick a provider and enter your API key
aicommits config set type=conventional

git add -p
aicommits                # generates a conventional commit draft

With roughly 9,000 GitHub stars in mid-2026, aicommits is the most popular dedicated CLI for this workflow. It is MIT-licensed and actively maintained.

Privacy / local models → OpenCommit + Ollama

OpenCommit (approximately 7,000 GitHub stars) differentiates with built-in Ollama support and GitMoji. If your codebase cannot send diffs to cloud APIs — regulated industries, proprietary code, or simply a preference for local-first tooling — OpenCommit with Ollama keeps everything on your machine.

npm install -g opencommit
oco config set model ollama/llama3.2
oco config set type conventional

git add -p
oco                       # generates a conventional draft via local model

OpenCommit also supports git hooks, so you can configure it as a team default without teaching anyone a new command.

Team default with zero habit change → gptcommit

gptcommit is a Rust binary that installs as a prepare-commit-msg hook. Once installed in a repo, every git commit automatically drafts a message from the staged diff. Team members do not need to learn a new command — they just git commit as usual and edit the pre-filled message.

cargo install gptcommit
gptcommit install          # installs the prepare-commit-msg hook

This is the lowest-training-cost path for teams. The hook drafts; the human edits and confirms. The main caveat: document your --no-verify policy so people know when bypassing is acceptable (emergencies only, with a follow-up amend).

Spec-strict interactive teams → cz-git / Commitizen + AI

Teams already using cz-git or Commitizen for interactive commit prompts can add AI suggestions into the flow. The interactive prompts enforce type and scope selection; AI fills in the description and body from the diff. This suits teams that want strict spec compliance with AI as an accelerator, not a replacement.

AI-native editor → Cursor generate commit message

Cursor — the AI-native VS Code fork — has a "Generate Commit Message" button in its Source Control panel. Because Cursor has full codebase context (not just the staged diff), it can produce more accurate scope and type suggestions. Project rules can enforce Conventional Commits across the team:

// .cursor/rules/commits.md
# Commit Message Rules
- Always use Conventional Commits: type(scope): description
- Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore
- Imperative mood, subject under 50 characters
- Explain why in the body, not what
- Include BREAKING CHANGE footer when applicable

JetBrains path → AI Assistant / AI Git Commit plugin

JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, GoLand, etc.) have AI Git Commit plugins available on the Marketplace. The AI Assistant integration can generate commit messages from the commit dialog. Multi-model support depends on the plugin and configuration — some support OpenAI, Gemini, Claude, and Ollama backends.

Desktop Git client → GitKraken AI

GitKraken Desktop includes AI-powered commit message generation and PR assistance on its paid AI tier. If your team prefers a visual Git client, this is a reasonable option. The same rules apply: configure for Conventional Commits and review before committing.

Agentic pair programmer → Aider auto-commits

Aider (with roughly 46,000 GitHub stars in mid-2026) is an open-source AI pair programmer that edits code and auto-commits after each edit loop. The commit messages are generated from the changes Aider made, not from a raw diff.

This is convenient, but it means commit quality becomes an agent UX problem. Aider's messages are decent by default but can be file-list-flavored for multi-file edits. The discipline here is to review each auto-commit and amend if the subject does not capture intent. Prefer small, focused prompts to Aider so each auto-commit is a logical unit rather than a mega-edit.

Zero install / teaching / pair programming on a call → ILAA Commit Message Generator

If you do not want to install a CLI, configure an IDE plugin, or send diffs to an API from your terminal, the ILAA Commit Message Generator is the fastest path. Copy your staged diff, paste it into the web tool, and get a Conventional Commits draft in seconds. No signup, no installation, no API key.

git diff --staged | pbcopy   # macOS (use xclip on Linux, wl-copy on Wayland)
# paste into /tools/commit-message-generator
# copy the result, then:
git commit

Use it as a teaching aid for new hires, a fallback when you are on a machine without your tools, or a zero-friction way to try Conventional Commits before committing to a full pipeline. It is also listed in our roundup of 20 free AI tools you can use without signing up.

2026 AI commit tool comparison

Prompt Templates and Config Patterns That Actually Work

The gap between a good AI commit draft and a bad one is almost always the prompt, not the model. Here are copy-paste templates for the most common scenarios.

Universal system prompt (copy-paste)

You are a senior engineer writing a Git commit message.

Input: a staged git diff.
Output rules:
1. Use Conventional Commits: type(optional-scope): subject
2. Types allowed: feat, fix, docs, style, refactor, perf, test, build, ci, chore
3. Subject: imperative mood, ≤50 chars preferred, no trailing period
4. Add a body only if the diff needs WHY, risk, or migration notes (wrap ~72 chars)
5. Do not list every file; capture intent
6. If the diff mixes unrelated concerns, say so and propose a split into N commits
7. Never invent ticket IDs; use only those present in the diff or branch name if provided
8. Flag possible secrets in the diff instead of writing a commit

Return:
- subject line
- optional body
- optional footer (BREAKING CHANGE / Refs)

This prompt works with any LLM — Claude, GPT, Gemini, Llama, or whatever your tool calls. Paste it as a system prompt or prepend it to the diff.

Copilot instructions (settings JSON)

{
  "github.copilot.chat.commitMessageGeneration.instructions": [
    {
      "text": "Use Conventional Commits: type(scope): description. Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore. Imperative mood. Subject under 50 characters. Prefer explaining why over listing files. Add a short body when behavior or risk is non-obvious."
    }
  ]
}

Add this to your VS Code settings.json (or workspace settings for team-wide enforcement). Copilot will follow these instructions on every commit generation without re-prompting.

CLI / shell one-liners

# Copy staged diff to clipboard, paste into ILAA generator
git diff --staged | pbcopy

# Pipe directly to a local Ollama model
git diff --staged | ollama run llama3.2 "Write a conventional commit message for this diff. Imperative mood, subject under 50 chars. Explain why in body if needed."

# Pipe to Claude CLI (if installed)
git diff --staged | claude -p "Write one conventional commit subject + optional body. Imperative. No file laundry list."

# aicommits with conventional type
aicommits --type conventional

These patterns let you mix and match models without changing your workflow. The diff is the input; the prompt is the constraint; the model is interchangeable.

Cursor rules snippet for commits

// .cursor/rules/commit-messages.md
# Commit Message Rules
- Always use Conventional Commits format: type(scope): description
- Allowed types: feat, fix, docs, style, refactor, perf, test, build, ci, chore
- Subject: imperative mood, ≤50 chars, no trailing period
- Body: explain WHY the change was made, not WHAT files changed
- Footer: include BREAKING CHANGE: or Closes #XXX when relevant
- If the diff touches multiple concerns, suggest splitting into separate commits
- Never invent ticket IDs

Cursor reads project rules automatically, so this file enforces commit format across your whole team without anyone needing to configure their editor individually.

"Why-focused" rewrite prompt (when the first draft is file-list fluff)

Rewrite this commit message so the subject states user-visible intent (why),
not implementation mechanics. Keep Conventional Commits format. Keep facts
accurate to the diff. Do not invent information.

Original: """{ai_draft_message}"""
Diff summary: """{short_diff_or_stat}"""

Use this as a second pass when the first AI draft is technically correct but reads like a changelog of filenames. It shifts the focus from "what files changed" to "why this change exists."

Breaking change / security-sensitive wording prompts

If the diff touches auth, crypto, payments, or PII:
- Prefer precise verbs (rotate, revoke, hash, redact, sanitize)
- Call out security impact in the body
- Never minimize risk in the subject
- Add BREAKING CHANGE footer if API contract or stored data shape changes

If the diff renames or removes a public API:
- Use the ! breaking marker: feat(api)!: ...
- Add BREAKING CHANGE: footer with migration guidance
- Reference the deprecation ticket if available

Scope-from-branch-name prompt

Branch name: {branch}
If branch matches ABC-123-description, put ABC-123 in the footer as Refs: ABC-123
Do not invent IDs. Use only IDs present in the diff or branch name.

Worked Examples: Before → AI Draft → Human Final

Five real-world shapes of diffs, showing where AI helps and where the human edit makes the difference.

Example A — Bugfix (auth token expiry)

Diff summary: Invalidates refresh token family when a user resets their password. Adds a regression test.

Bad human message: fixed stuff

Naive AI draft: Update auth.js and session.js

Human final:

fix(auth): revoke refresh tokens after password reset

Prevents session reuse if a password is changed while a refresh
token is still valid. Adds regression test for token family revoke.
Closes #1842

What the human added: The type (fix), the scope (auth), the intent ("revoke refresh tokens after password reset"), the reason in the body, and the ticket reference. The AI draft had none of these.

Example B — Feature with scope

Diff summary: Adds trigram-based fuzzy matching for product SKU searches. p95 query latency increases by 12ms on staging.

Naive AI draft: Add fuzzy search functionality to search module

Human final:

feat(search): add fuzzy match for product SKUs

Uses trigram index on sku_normalized. p95 query +12ms on staging.
Acceptable per team SLA; see perf benchmark in PR description.

What the human added: The scope (search), the performance note (which the model could not infer from the diff alone — it was measured separately), and the SLA context.

Example C — Refactor that looks like a feature to naive AI

Diff summary: Extracts email verification logic out of UserService into a new VerifyEmailService class. No behavior change.

Naive AI draft: feat: improve UserService structure

Human final:

refactor(users): extract email verification into VerifyEmailService

No behavior change. Prepares for #910 where verification needs
to be callable from the signup flow without a full user save.

What the human corrected: The type — this is refactor, not feat. The AI saw new code and assumed "feature." The human also added the motivation (preparing for issue #910), which is invisible in the diff.

Example D — Dependency bump vs real behavior change

Diff summary: package-lock.json updates lodash from 4.17.20 to 4.17.21.

Naive AI draft: Update package-lock.json with new dependencies

Human final:

chore(deps): bump lodash to 4.17.21

Security patch for prototype pollution (CVE-2021-23337).
No API changes; drop-in replacement.

What the human added: The CVE reference and the "drop-in replacement" note. The AI saw a lockfile change and described the file; the human explained why it matters and that it is safe.

Example E — Agent multi-file edit: how to split commits

Scenario: You asked Aider to "add a rate limiter to the API and update the docs." Aider edited middleware/rateLimit.js, server.js, docs/api.md, and package.json (added express-rate-limit), then auto-committed with "Add rate limiting and update docs".

This is one mega-commit that mixes a feature, a dependency addition, and documentation. To clean it up:

# Soft reset the agent commit
git reset --soft HEAD~1

# Stage and commit the dependency first
git add package.json package-lock.json
git commit -m "build(deps): add express-rate-limit"

# Stage and commit the feature
git add middleware/rateLimit.js server.js
git commit -m "feat(api): add rate limiting middleware

100 req/min per IP. Returns 429 with Retry-After header.
Configure via RATE_LIMIT_PER_MIN env var."

# Stage and commit the docs
git add docs/api.md
git commit -m "docs(api): document rate limit headers and 429 response"

Now your history has three focused commits instead of one blob. Each one is independently revertable, and git bisect can isolate whether the rate limiter or the dependency caused an issue.

Privacy, Secrets, and Compliance

What leaves your machine when you generate a message

When you use a cloud-based AI commit tool — Copilot, aicommits with a cloud provider, or the ILAA generator — your staged diff is sent to an external API. That diff may contain:

• API keys or tokens hardcoded in config files
• Customer data in test fixtures or seed files
• Internal URLs, hostnames, or infrastructure details
• Unreleased feature names or product code
• Proprietary algorithms or business logic

Treat sending a diff to a cloud LLM the same way you would treat pasting it into a public chat. If you would not paste it into ChatGPT, do not send it to a cloud commit tool.

Scrub checklist before cloud LLMs

1. Use git add -p — exclude any hunk containing secrets, even if the file is .gitignored. If a secret is already staged, unstage it: git reset HEAD path/to/file.
2. Run a secret scanner pre-commit. Tools like gitleaks, trufflehog, or GitHub's built-in secret scanning catch what you miss.
3. Review test fixtures. Ensure test data does not contain real PII or production database snapshots.
4. Check for internal URLs that reveal infrastructure topology (e.g., internal-api.corp.company.com).
5. Use a local model if the diff is too sensitive to send externally (see below).

Local model path (Ollama / LM Studio)

Both aicommits and OpenCommit support Ollama and LM Studio as providers. This means the diff never leaves your machine — the model runs locally.

# aicommits with Ollama
aicommits config set provider=ollama
aicommits config set model=llama3.2
aicommits config set type=conventional

# OpenCommit with Ollama
oco config set model ollama/llama3.2

Local models are less capable than frontier cloud models, but for commit messages — a constrained, well-scoped task — they are more than sufficient. A 7B–8B parameter model produces good Conventional Commits drafts when given a strong system prompt.

Enterprise policy notes

For enterprise teams, define a written allowlist of approved AI commit tools and providers. Key policy questions:

• Which cloud providers are approved? (e.g., Azure OpenAI, AWS Bedrock, Google Vertex AI)
• Is local-model usage mandatory for certain repository classifications?
• What is the data retention policy of the provider? (Most API providers do not train on inputs by default, but verify.)
• Are there repositories where AI commit tools are prohibited entirely?
• Who is responsible for reviewing AI-drafted messages before they land on protected branches?

Document the answers in your engineering handbook. A tool allowlist prevents shadow IT and ensures everyone uses the same privacy posture.

Team Playbook

Shared Conventional Commits + scopes dictionary

Agree on a fixed set of scopes so that git log --grep "fix(auth)" finds every auth fix. Publish the list in your README or contributing guide:

# Scopes
auth       — authentication, sessions, tokens
billing    — payments, invoices, tax
search     — search API, indexing, query
api        — public API surface (v1, v2)
ui         — frontend components and pages
db         — migrations, schema, indexes
ci         — CI/CD pipeline config
deps       — dependency updates
docs       — documentation

When AI tools see consistent scopes in your history, they tend to suggest the right ones. When scopes are random, models pick whatever string appears in the file path.

commitlint + husky (or lefthook)

# Install commitlint with conventional config
npm install --save-dev @commitlint/cli @commitlint/config-conventional

# Create commitlint config
echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

# Install husky for git hooks
npm install --save-dev husky
npx husky init

# Add commit-msg hook
echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

Now any commit that does not match Conventional Commits is rejected locally before it reaches the remote. Fast feedback, no CI round-trip.

Hooks draft, humans approve — never silent force on main

A prepare-commit-msg hook (like gptcommit or OpenCommit) should draft the message in the editor, not commit silently. The human reviews, edits, and saves. This preserves review culture while removing the blank-page problem.

On protected branches (main, release/*), never allow AI to auto-commit without review. Branch protection rules should require PR review even when the commit message was AI-generated.

PR description AI as a second stage

After good commits, AI can draft PR descriptions from the branch's commit log. Tools like Graphite (stacked PR summaries), What The Diff (changelog prose), and Copilot's PR summary feature read the conventional commits on a branch and generate a structured PR description.

This is the continuum: commit → PR → review → changelog. Each stage benefits from AI drafting with human editing. Start with good commits, and every downstream stage gets easier.

Onboarding one-pager for new hires

Give new engineers a single page that covers:

1. We use Conventional Commits. Here are the types and scopes.
2. Install aicommits (or Copilot, or OpenCommit — pick the team default).
3. Run git add -p before generating. One logical change per commit.
4. Edit the AI draft: add the why, the ticket, and any risk notes.
5. commitlint will reject non-conventional messages. If it does, fix and recommit.
6. Never commit secrets. Use gitleaks pre-commit if you are unsure.
7. For sensitive repos, use the local Ollama model path. Ask your tech lead which repos require this.

This page takes 10 minutes to write and saves every new hire from their first bad commit.

Anti-Patterns to Avoid in 2026

• Blind accept of AI subjects on release trains. When you are about to tag a release, read every commit subject since the last tag. A wrong feat that should be fix can trigger an incorrect minor version bump via semantic-release.
• One mega-commit "AI summary of the week." If you let an agent code for a day and commit once with an AI summary, you lose bisect granularity. Split into logical units.
• Inventing product names or dead tools. Do not cite tools that do not exist or have been abandoned. Stick to the verified 2026 tools listed above.
• Committing .env because the model did not warn you. AI commit tools describe diffs; they do not audit for secrets. Use git add -p and a secret scanner. The model will happily write feat: add .env file with database credentials — do not let it.
• Using AI to justify noisy history instead of interactive rebase discipline. If your branch has 30 commits and 25 are "wip", do not squash them into one AI-summarized commit. Use git rebase -i to clean up, then let AI draft the final messages for the squashed commits.
• Skipping the human edit because "the AI is smart enough." Frontier models are impressive, but they do not know your ticket numbers, your product roadmap, or why a seemingly mechanical refactor is actually a load-bearing architecture decision. The 10-second human edit is the whole point.

How Coding Agents Change Commit Discipline

The rise of agentic coding tools — Aider, Claude Code, Cursor's agent mode, and similar — creates a new challenge: commit messages written by the same agent that wrote the code. This is different from a human using AI as a drafting assistant. Here the agent is both author and historian.

Aider: auto-commits as a byproduct

Aider commits after each edit loop by default. The messages are generated from the changes and are generally decent — often following Conventional Commits if configured. But they can be generic for multi-file edits.

Best practice: Use small, focused prompts with Aider. Instead of "add rate limiting and update the docs and add tests," do three sequential prompts: "add rate limiting middleware," "update the API docs for rate limiting," "add tests for the rate limiter." Each produces a focused auto-commit.

Claude Code and similar agent CLIs

Agent CLIs like Claude Code can be configured with custom /commit slash commands that pipe the staged diff through a constrained prompt. This gives you the same control as a CLI tool but inside an agent session.

# Example custom command for an agent CLI
/commit: Run `git diff --staged` and write a Conventional Commits message.
  - type(scope): subject, imperative, ≤50 chars
  - Body explains why, wraps at 72
  - Flag secrets, suggest splits for mixed diffs
  - Then run git commit with the message

Reviewing agent commits

When an agent auto-commits, review the message before pushing. If the message is file-list fluff, amend it:

git commit --amend -m "fix(auth): revoke refresh tokens after password reset" -m "Prevents session reuse after password change."

If the agent made a mega-commit, soft-reset and split:

git reset --soft HEAD~1
# re-stage and commit in logical units

The rule: agents draft, humans own history. This does not change with better models. It is a governance principle, not a capability gap.

Frequently Asked Questions

Is it safe to send my git diff to an AI commit tool?

Staged diffs can contain secrets, customer data, or proprietary logic. Cloud-based tools (Copilot, aicommits with cloud providers, the ILAA generator) send your diff to an external API. Use local models via Ollama or LM Studio for sensitive codebases, run a secret scanner like gitleaks pre-commit, and always review with git add -p before staging. Treat a diff like any other code you would send to a third party.

Should every commit message be written by AI?

No. AI is best as a fast first draft for routine changes — dependency bumps, formatting, obvious fixes, tests. You should still write the subject and body yourself for commits that carry architecture intent, security implications, breaking changes, or product decisions. The model does not know your roadmap; it only knows your diff.

Conventional Commits vs free-form messages when using LLMs — which wins?

Conventional Commits wins for any team. It keeps history machine-readable, enables semantic-release and changelog automation, and gives LLMs a constrained output format that produces more consistent drafts. Free-form messages are fine for solo projects or quick experiments, but the moment you have a team, CI, or release automation, Conventional Commits is the shared language that makes all of it work.

How do I make GitHub Copilot always use Conventional Commits?

Add the github.copilot.chat.commitMessageGeneration.instructions setting in your VS Code settings.json (or workspace settings) with a text instruction specifying Conventional Commits, imperative mood, allowed types, and a 50-character subject limit. Copilot will follow these instructions on every commit generation without re-prompting. See the exact JSON snippet in the Prompt Templates section above.

What is the best free AI git commit message generator in 2026?

It depends on your workflow. For a zero-install web tool, the ILAA Commit Message Generator is free with no signup. For terminal users, aicommits is free and open-source (MIT) — you only pay for the LLM API, and it supports Ollama for zero-cost local generation. For GitHub shops, Copilot's free tier includes commit generation in VS Code.

Can AI write PR descriptions and changelogs too?

Yes. Most AI code review and SCM tools can summarize a branch's commits into a PR description. Copilot generates PR summaries on github.com. Graphite produces stacked-PR summaries. What The Diff generates changelog prose. Start with the AI draft, then add the business context, risk assessment, and deployment notes that a machine cannot infer from commits alone. Good commits make good PR descriptions automatically.

How do coding agents (Aider, Claude Code, Cursor) change commit discipline?

Agents produce more commits at higher speed, which means commit quality can degrade faster unless you apply discipline. Prefer small, focused prompts so each agent auto-commit is a logical unit. Review agent commit messages before pushing, and amend or split if the message is generic. The principle is the same: AI drafts the what, you own the why. Agents do not change that — they just raise the volume.

Will AI commit messages break git bisect or semantic-release?

Only if you blindly accept wrong types. A commit labeled feat that is actually a fix will cause semantic-release to bump the minor version instead of the patch — a false signal to downstream consumers. A commit labeled fix that is actually a feat hides a new feature from the changelog. The 10-second human review of the type is the safeguard. If you use semantic-release, review every feat and BREAKING CHANGE before a release tag.

Conclusion: Your 2026 Commit OS

The workflow is simple, and it does not change with new models or tools:

1. Stage one logical change with git add -p.
2. Draft with AI — Copilot, aicommits, OpenCommit, Cursor, or the ILAA generator.
3. Edit the draft in 10 seconds: fix the type, add the why, attach the ticket.
4. Validate with commitlint + husky.
5. Ship and let the conventional format feed your PR descriptions, changelogs, and release notes.

AI drafts the what. You own the why. That is the entire contract.

Try it now: paste your next staged diff into the ILAA Commit Message Generator — no signup, no install. Then use the AI Code Reviewer to catch issues before merge. Good commits feed clean PRs; clean PRs feed reliable releases.

Related reading:

• AI Code Reviewer Guide: Catch Bugs Before Merge
• 20 Free AI Tools You Can Use Without Signing Up
• Generate Regex from Plain English with AI
• MCP vs API: When to Use Each
• Build Your First MCP Server

Last updated 17 August 2026. Tool names and features verified against official documentation and GitHub repositories on that date.