Git Commit Message Guide & Templates

PullNotifier

Git Commit Message Guide

A well-crafted git commit message is the best way to communicate context about a change to your team and your future self. Great commit messages make your project history readable, your code reviews faster, and your debugging sessions shorter. Below you'll find free git commit message templates you can copy and use immediately, a comprehensive guide to writing effective commit messages, and an interactive validator to check your messages against best practices. Whether you're looking for a git commit message template for your team or learning the conventions for the first time, this page has everything you need.

Standard Commit Message Template

The classic .gitmessage template file with commented guidelines. Save this as ~/.gitmessage and configure Git to use it automatically.

# <type>: <subject>
#
# <body>
#
# <footer>
#
# --- COMMIT GUIDELINES ---
#
# Subject line:
#   - Limit to 50 characters
#   - Capitalize the first letter
#   - Do not end with a period
#   - Use imperative mood ("Add feature" not "Added feature")
#
# Body:
#   - Wrap at 72 characters
#   - Explain WHAT and WHY, not HOW
#   - Separate from subject with a blank line
#
# Footer:
#   - Reference issues: Closes #123, Fixes #456
#   - Note breaking changes: BREAKING CHANGE: description
#
# Types: feat, fix, docs, style, refactor, test, chore, perf, ci, build
#
# Example:
#   feat: Add email notification for PR reviews
#
#   Users can now opt in to email notifications when a reviewer
#   requests changes on their pull request. This reduces the time
#   to respond to review feedback.
#
#   Closes #742

Conventional Commits Template

Follows the Conventional Commits specification (v1.0.0). Pairs well with semantic-release and automated changelogs.

# <type>(<scope>): <description>
#
# [optional body]
#
# [optional footer(s)]
#
# --- CONVENTIONAL COMMITS FORMAT ---
#
# Types:
#   feat:     A new feature (correlates with MINOR in SemVer)
#   fix:      A bug fix (correlates with PATCH in SemVer)
#   docs:     Documentation only changes
#   style:    Formatting, missing semi colons, etc; no code change
#   refactor: Code change that neither fixes a bug nor adds a feature
#   perf:     Code change that improves performance
#   test:     Adding missing tests or correcting existing tests
#   build:    Changes to the build system or external dependencies
#   ci:       Changes to CI configuration files and scripts
#   chore:    Other changes that don't modify src or test files
#   revert:   Reverts a previous commit
#
# Scope:
#   Optional noun describing the section of the codebase
#   e.g., api, auth, ui, parser, config
#
# Breaking Changes:
#   Add ! after type/scope: feat!: Remove deprecated API
#   Or add footer: BREAKING CHANGE: description of what changed
#
# Examples:
#   feat(auth): Add OAuth2 login with GitHub
#   fix(api): Handle null response from payment gateway
#   docs: Update README with new installation steps
#   feat!: Drop support for Node 14

Minimal Team Template

A lightweight commit message template for small teams who want structure without overhead.

# Subject: What does this commit do? (max 50 chars)
#
# Body: Why is this change needed? (wrap at 72 chars)
#
# Ticket: PROJ-XXX (if applicable)
#
# Checklist:
# - [ ] Tests pass
# - [ ] Documentation updated (if needed)
# - [ ] No console.log / debug code left behind

Bug Fix Commit Template

A specialized template for bug fix commits that captures root cause and verification details.

fix: <short description of the fix>

# Problem:
# <Describe the bug — what was happening?>

# Root Cause:
# <What caused the bug?>

# Solution:
# <What does this fix do?>

# Testing:
# <How was this fix verified?>

# Closes #<issue-number>

Feature Commit Template

A specialized template for feature commits that provides context on the motivation and scope.

feat: <short description of the feature>

# Motivation:
# <Why is this feature needed? What problem does it solve?>

# Changes:
# - <Change 1>
# - <Change 2>
# - <Change 3>

# Notes:
# <Any caveats, follow-up work, or migration steps?>

# Relates to #<issue-number>

What Is a Git Commit Message?

A git commit message is a short description attached to each commit in a Git repository. It records why a change was made and provides context for anyone reading the project history — whether that's a teammate reviewing a pull request, a future developer investigating a bug, or your future self trying to understand code you wrote six months ago.

Every git commit message has up to three parts:

Subject line — A brief summary of the change (50 characters max). This is the only mandatory part and is what most tools display in logs and history views.
Body — An optional longer explanation of what changed and why. Separated from the subject by a blank line and wrapped at 72 characters.
Footer — Optional metadata like issue references (Closes #123), co-authors, or breaking change notices.

Well-written commit messages transform your git log from an opaque list of diffs into a readable narrative of how your project evolved. They are one of the highest-leverage habits a developer can adopt.

The 7 Rules of Great Git Commit Messages

These rules, popularized by Chris Beams, are widely considered the standard for writing git commit messages. Follow them and your project history will be clean, consistent, and useful.

Separate subject from body with a blank line.
Many Git tools treat the first line as the subject and everything after the blank line as the body. Without the blank line, commands like git log --oneline and git shortlog won't work correctly.
Limit the subject line to 50 characters.
This keeps the subject readable in git log, GitHub's commit list, and other tools. If you can't summarize the change in 50 characters, the commit may be doing too much.
Capitalize the subject line.
Begin the subject with a capital letter. This is a simple convention that makes the history look clean and professional.
Do not end the subject line with a period.
Trailing punctuation is unnecessary in a subject line. Space is precious when you're limited to 50 characters.
Use the imperative mood in the subject line.
Write as if you're giving a command: "Add feature", "Fix bug", "Remove deprecated method". A properly formed subject should complete the sentence: "If applied, this commit will your subject line."
Wrap the body at 72 characters.
Git doesn't wrap text automatically. Wrapping at 72 characters ensures the body is readable in terminal windows and tools that display commit messages.
Use the body to explain what and why, not how.
The code diff shows how the change was made. The commit message should explain what motivated the change and why this approach was chosen over alternatives.

Commit Message Validator

Type a commit message below to check it against the rules above. The validator provides real-time feedback on your subject line and body formatting.

Subject line

0/50

Body (optional)

Validation

○

Subject line ≤ 50 characters

○

Capitalized subject line

○

No trailing period in subject

○

Imperative mood

○

Blank line between subject and body

○

Body lines ≤ 72 characters

Conventional Commits

Conventional Commits is a specification that adds structure to commit messages by requiring a type prefix. The format is type(scope): description. This convention enables automated tooling — changelog generation, semantic versioning, and release automation — and makes commit history easy to scan.

Type	Description	SemVer	Example
feat	A new feature	MINOR	`feat(auth): Add SSO login`
fix	A bug fix	PATCH	`fix(api): Handle null user response`
docs	Documentation changes	—	`docs: Update API reference`
style	Formatting, no code change	—	`style: Fix indentation in utils`
refactor	Code change, no new feature or fix	—	`refactor: Extract auth middleware`
perf	Performance improvement	PATCH	`perf: Cache database queries`
test	Adding or fixing tests	—	`test: Add unit tests for parser`
build	Build system or dependencies	—	`build: Upgrade webpack to v5`
ci	CI configuration changes	—	`ci: Add GitHub Actions workflow`
chore	Maintenance tasks	—	`chore: Update .gitignore`

To indicate a breaking change, add ! after the type (e.g., feat!: Remove v1 API) or include a BREAKING CHANGE: footer in the commit body. Breaking changes correlate with a MAJOR version bump in SemVer.

Good vs Bad Commit Messages

The difference between a helpful and unhelpful commit message is often obvious in hindsight. Here are side-by-side examples:

Bad	Good	Why
`fix bug`	`Fix race condition in session cleanup`	Specificity — "fix bug" gives no context for debugging
`updated stuff`	`Update payment gateway to Stripe API v3`	Imperative mood and specific scope
`asdfgh`	`Add input validation for email field`	Meaningful description vs. keyboard mashing
`WIP`	`Add draft implementation of user search`	Even in-progress work should be described
`fixed the thing that john broke last tuesday when he pushed the change to the auth module`	`Fix token expiry check in auth middleware`	Concise, blameless, under 50 characters
`changes.`	`Refactor user service to use repository pattern`	Describes the change and the approach
`Added feature and also fixed some bugs and updated deps`	Split into 3 separate commits	One commit should do one thing — atomic commits

How to Set Up a Git Commit Message Template

Git supports commit message templates natively. When configured, the template appears in your editor every time you run git commit (without the -m flag), giving you a consistent starting point.

Create the template file.
Save one of the templates above to a file — for example, ~/.gitmessage. Lines starting with # are comments and won't appear in the final commit message.
Configure Git to use it globally.
Run: git config --global commit.template ~/.gitmessage. This tells Git to use your template for all repositories.
For a single project only.
Run the same command without --global from inside the repository: git config commit.template .gitmessage. This is useful when different projects have different conventions.
Commit as usual.
Run git commit (without -m). Your editor will open with the template pre-filled. Write your message, save, and close the editor.

For teams, commit the template file to your repository (e.g., as .gitmessage at the root) and add the setup command to your onboarding documentation.

Git Commit Message Tools

These tools help teams enforce commit message conventions automatically:

Commitizen — An interactive CLI that prompts you to fill in commit message fields step by step. Ensures every commit follows the Conventional Commits format. Install with npm install -g commitizen and use git cz instead of git commit.
Commitlint — A linter for commit messages. Runs as a Git hook and rejects commits that don't match your configured rules. Commonly paired with Husky to run automatically on every commit.
Husky — A tool for managing Git hooks. Use it to run Commitlint on the commit-msg hook, ensuring every commit message is validated before it's accepted.
Gitmoji — Adds emoji prefixes to commit messages for visual categorization (e.g., ✨ for new features, 🐛 for bug fixes). Popular in open-source projects for making commit logs scannable at a glance.
semantic-release — Automates versioning and changelog generation based on Conventional Commits. When your commit messages follow the convention, semantic-release can determine the next version number and publish a release automatically.

Commit Messages and Pull Requests

How commit messages interact with pull requests depends on your merge strategy. Understanding this relationship helps you decide where to invest effort in writing good messages.

Merge commit — All individual commits are preserved. Each commit message matters because they all appear in the main branch history. This strategy requires discipline in writing good messages throughout development, not just at merge time.
Squash and merge — All commits in the PR are squashed into a single commit. GitHub defaults the squash message to the PR title and description. With this strategy, the PR title becomes the most important message — it's what appears in git log.
Rebase and merge — Individual commits are rebased onto the target branch. Like merge commits, each commit message is preserved. This strategy produces the cleanest linear history but requires well-written individual commits.

Use auto-close keywords in your commit messages or PR descriptions to link changes to issues: Closes #123, Fixes #456, Resolves #789. GitHub will automatically close the referenced issue when the commit is merged to the default branch.

Good commit messages make code reviews faster. When a reviewer can read the commit message and understand the intent before looking at the diff, the review focuses on correctness and design rather than trying to understand what the change does. Tools like PullNotifier send GitHub pull request notifications to Slack, keeping your team informed about PRs that need review, merges, and CI status — closing the loop between commit messages and team communication.

FAQ

What is a good git commit message?

A good git commit message is concise (50 characters or fewer for the subject), uses imperative mood ("Add feature" not "Added feature"), starts with a capital letter, omits trailing periods, and explains the why behind the change. If the change is non-trivial, include a body wrapped at 72 characters that provides additional context.

How long should a git commit message be?

The subject line should be 50 characters or fewer. If you include a body, separate it from the subject with a blank line and wrap each line at 72 characters. There is no hard limit on the body length — include as much context as needed to explain the change.

What is Conventional Commits?

Conventional Commits is a specification for structuring commit messages in the format "type(scope): description". Types include feat, fix, docs, style, refactor, test, and chore. This convention enables automated changelog generation, semantic versioning, and makes commit history easier to parse. It is widely adopted in open-source and enterprise projects.

How do I set up a git commit message template?

Create a template file (e.g., ~/.gitmessage) with your preferred format and comments, then run "git config --global commit.template ~/.gitmessage". Git will use this template every time you run "git commit" without the -m flag. You can also set project-specific templates by omitting --global.

Should I use past tense or imperative mood in commit messages?

Use imperative mood — "Add feature", "Fix bug", "Remove deprecated method". This matches the convention used by Git itself (e.g., "Merge branch", "Revert commit") and reads as a command: "If applied, this commit will [your subject line]." Avoid past tense ("Added", "Fixed") and present participle ("Adding", "Fixing").

What is the difference between a commit message subject and body?

The subject is the first line of the commit message — a brief summary of the change (50 characters max). The body is optional additional text separated from the subject by a blank line. The body explains what changed and why, wrapped at 72 characters. Many tools (GitHub, git log --oneline) only show the subject, so it must stand on its own.

Related resources: Pull Request Templates · Code Review Checklist

Built byPullNotifier— get GitHub pull request notifications directly on Slack.

Never miss a PR review, merge, or CI failure again.