Git Commit Message Templates

Reusable conventional-commit and PR-ready message templates that expand in your terminal and editor.

Template Category Overview

Consistent commit messages make a repository's history readable, enable automated changelogs, and make code review faster — but typing a properly structured Conventional Commit by hand every time is tedious enough that most developers fall back to one-line summaries. A text expander solves this by turning a short trigger into a full commit scaffold with the type, scope, summary, body, and footer already laid out, so you fill in the specifics instead of remembering the format. Because Lightning Assist works system-wide — including in the terminal, where most commits actually happen, and in VS Code's commit box — the same templates work whether you commit from the command line, your IDE, or a Git GUI. Push-to-talk voice can even dictate the longer body paragraph when your hands are off the keyboard mid-debug.

When to Use These Templates

Use commit message templates on every commit, but they pay off most on the commits that matter later: bug fixes you will revisit, breaking changes that affect other teams, and any commit in a repo that auto-generates releases or changelogs from commit history. If your project uses Conventional Commits, semantic-release, or any changelog automation, a consistent scaffold is not just tidiness — it is what makes the tooling work at all. Even on solo projects, a readable git log written to a consistent format saves real time when you bisect a regression or try to remember why a change was made six months ago.

Example Templates in This Category

Conventional Commit scaffold: type, optional scope, summary, body, and footer with ticket reference.
Fix commit with bug context: what broke, the fix, and the issue it closes.
Breaking-change commit: the change plus a clearly marked BREAKING CHANGE footer for release tooling.

Example Templates in Practice

Conventional Commit scaffold

The everyday template for any commit, following the Conventional Commits specification that powers automated versioning and changelog tools. The structure is a type (feat, fix, chore, docs, refactor, test, etc.), an optional scope in parentheses, a concise imperative summary under about fifty characters, a blank line, then a body explaining the why, and a footer for ticket references. Keep this on a short trigger like ;cc so it expands in the terminal before you write the message. Filling a consistent scaffold every time is what makes a git log actually useful months later, and it is the difference between a release tool that can auto-generate a changelog and one that cannot.

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

Fix commit with bug context

Bug-fix commits are the ones future-you most needs to understand, so they deserve more than "fix bug." Capture three things: what was broken (the observable symptom), what the fix does, and which issue it closes so the tracker updates automatically. The "Closes #" footer is what links the commit to your issue tracker and auto-closes the ticket on merge in most platforms. Keep this on a trigger like ;fix. When you are deep in a debugging session and want to record the root cause in plain English, push-to-talk voice lets you dictate the body without breaking flow, and AI Enhance can tighten a rambling dictated explanation into a clean paragraph.

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

Breaking-change commit

When a commit changes an API, a config format, or any contract other code depends on, the breaking change must be marked explicitly so release tooling triggers a major version bump and the changelog warns users. The Conventional Commits standard uses a BREAKING CHANGE: footer (or a ! after the type) for exactly this. Spell out what broke and, critically, what consumers must do to migrate — a breaking change without a migration note just turns into a flood of support questions. Keep this on a deliberate trigger like ;ccbreak so you only reach for it when you genuinely mean it, since mislabeling a breaking change is worse than not labeling one.

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

How to Get Started

Start with the general Conventional Commit scaffold on a short trigger like ;cc, with placeholders for type, scope, summary, body, and ticket. Add a ;fix variant pre-filled with the fix type and a "Closes #" footer, and a ;ccbreak variant with the BREAKING CHANGE footer for the rare but important breaking commits. Type the trigger in your terminal or your editor's commit box and it expands inline as you type — no hotkey needed, and it works the same in both because the expansion is system-wide. Once the scaffolds feel natural, add PR-description and code-review-reply templates so the whole change-submission flow is consistent.

Pro Tips

Keep the summary line under ~50 characters and in the imperative ("add", not "added") — most git tooling and reviewers expect this convention.
Use a "Closes #[issue]" footer on fix commits so merging the change auto-closes the linked ticket in your tracker.
Reserve the breaking-change template for genuine contract changes, and always include the migration step — a breaking note without it just creates support load.
Dictate the commit body with push-to-talk when your hands are off the keyboard mid-debug, then use AI Enhance to tighten the wording.