Git Commit Message Generator

Category: Version Control October 15, 2025

Generate clear, conventional commit messages that follow best practices and team standards.

GitVersion ControlCommit MessagesConventional Commits
# Git Commit Message Generator

Generate clear, informative commit messages following conventional commits and best practices.

## Conventional Commits Format

():

```

Types

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation only
  • style: Code style (formatting, missing semi colons, etc)
  • refactor: Code change that neither fixes a bug nor adds a feature
  • perf: Performance improvement
  • test: Adding or updating tests
  • build: Build system or external dependencies
  • ci: CI configuration files and scripts
  • chore: Other changes that don’t modify src or test files
  • revert: Reverts a previous commit

Scope

Optional, indicates what part of the codebase:

  • Component name (auth, api, ui)
  • Module name (user, payment)
  • Feature area (dashboard, settings)

Subject

  • Use imperative mood (“add” not “added” or “adds”)
  • Don’t capitalize first letter
  • No period at the end
  • Limit to 50 characters
  • Be specific and concise

Body

  • Wrap at 72 characters
  • Explain what and why, not how
  • Separate from subject with blank line
  • Use bullet points for multiple changes
  • Reference issues (Closes #123, Fixes #456)
  • Note breaking changes (BREAKING CHANGE:)
  • Mention co-authors

Examples

Feature Addition

feat(auth): add OAuth2 authentication

Implement OAuth2 authentication flow with Google and GitHub providers.
Users can now sign in using their existing accounts.

Features:
- OAuth2 authorization code flow
- Automatic user creation on first login
- Token refresh mechanism
- Secure session management

Closes #234

Bug Fix

fix(api): prevent null pointer exception in user lookup

Add null check before accessing user.email property in getUserByEmail.
This was causing crashes when users were soft-deleted but still
referenced in other tables.

Fixes #567

Breaking Change

feat(api)!: change user response format

BREAKING CHANGE: User API now returns nested address object instead
of flat address fields.

Before:
{
  "name": "John",
  "street": "123 Main St",
  "city": "Boston"
}

After:
{
  "name": "John",
  "address": {
    "street": "123 Main St",
    "city": "Boston"
  }
}

Migration guide: https://docs.example.com/migration/v2

Closes #890

Documentation

docs(readme): update installation instructions

- Add prerequisites section
- Update npm commands to use npm 9
- Add troubleshooting section for common issues
- Fix broken links to API documentation

Refactoring

refactor(utils): extract date formatting into helper function

Extract repeated date formatting logic into reusable formatDate utility.
This reduces duplication and makes date formatting consistent across
the application.

No functional changes.

Performance

perf(database): add index on user_id column

Add composite index on (user_id, created_at) to improve query
performance for user activity feed.

Before: 2.3s average query time
After: 45ms average query time (98% improvement)

Closes #445

Testing

test(auth): add integration tests for login flow

Add comprehensive integration tests covering:
- Successful login with valid credentials
- Failed login with invalid password
- Account lockout after 5 failed attempts
- Session expiration handling
- Token refresh mechanism

Test coverage increased from 65% to 92%.

Best Practices

Do

✅ Use imperative mood (add, fix, update) ✅ Keep subject line under 50 characters ✅ Explain why the change was made ✅ Reference related issues ✅ Break down large changes into smaller commits ✅ Review commit message before pushing

Don’t

❌ Use past tense (“added feature”) ❌ Be vague (“fixed stuff”, “updates”) ❌ Include WIP commits in main branch ❌ Combine unrelated changes ❌ Forget to explain the why ❌ Use generic messages (“fix bug”)

Message Quality Checklist

  • Type is appropriate
  • Scope is specified (if applicable)
  • Subject is clear and concise
  • Uses imperative mood
  • Subject under 50 characters
  • Body explains what and why
  • Body wrapped at 72 characters
  • References relevant issues
  • Breaking changes noted in footer
  • No typos or grammar errors

Commit Message Templates

Setup Git Template

# Create template file
cat > ~/.gitmessage << 'EOF'
# <type>(<scope>): <subject>

# <body>

# <footer>

# Type: feat, fix, docs, style, refactor, perf, test, build, ci, chore
# Scope: component or feature area (optional)
# Subject: imperative mood, no period, max 50 chars
# Body: explain what and why (wrap at 72 chars)
# Footer: reference issues, breaking changes
EOF

# Configure git to use template
git config --global commit.template ~/.gitmessage

Pre-commit Hook for Validation

#!/bin/sh
# .git/hooks/commit-msg

commit_msg_file=$1
commit_msg=$(cat "$commit_msg_file")

# Check conventional commit format
if ! echo "$commit_msg" | grep -qE '^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\(.+\))?: .{1,50}'; then
  echo "Error: Commit message doesn't follow conventional commits format"
  echo "Format: <type>(<scope>): <subject>"
  exit 1
fi

# Check subject length
subject=$(echo "$commit_msg" | head -n1)
if [ ${#subject} -gt 72 ]; then
  echo "Error: Subject line is too long (${#subject} > 72)"
  exit 1
fi

exit 0

Team Guidelines

For Small Changes

fix(typo): correct spelling in error message

For Feature Work

feat(dashboard): add real-time analytics chart

Implement WebSocket connection for live data updates.
Chart automatically refreshes every 5 seconds with new data.

Closes #123

For Urgent Fixes

fix(security): patch XSS vulnerability in comment rendering

Sanitize user-generated HTML before rendering to prevent XSS attacks.
All user input is now escaped using DOMPurify.

SECURITY: CVE-2025-1234
Fixes #999