Skip to content
app.shubraj.com

Git Commit Message Generator

Generate properly formatted commit messages following the Conventional Commits specification.

e.g. Closes #123, Refs #456

Commit message

More in Data Formatters

UUID/ULID Generator

Unix Timestamp Converter

Regex Tester

Text Diff Checker

Markdown ↔ HTML Converter

CSV ↔ JSON Converter

Generate Proper Git Commit Messages with Conventional Commits

Create well-structured, standardized commit messages that follow the Conventional Commits specification. This tool helps developers maintain consistent commit history, improve code review efficiency, and enable automated versioning and changelog generation.

Why Use Conventional Commits?

  • Consistency: Standardized format makes it easier to understand commit history at a glance.
  • Automation: Enables automated version bumping based on commit types (feat = minor, fix = patch, BREAKING CHANGE = major).
  • Changelog Generation: Tools can automatically generate changelogs from commit messages.
  • Better Code Reviews: Clear commit messages help reviewers understand the purpose of changes quickly.
  • Searchability: Easy to search commit history by type (e.g., find all bug fixes).

Commit Message Structure

A conventional commit message follows this format:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Common Commit Types

  • feat: A new feature that adds functionality.
  • fix: A bug fix that resolves an issue.
  • docs: Documentation-only changes (README, comments, etc.).
  • style: Code style changes that don't affect functionality (formatting, whitespace).
  • refactor: Code restructuring without changing behavior.
  • perf: Performance optimizations and improvements.
  • test: Adding or modifying tests.
  • build: Changes to build system, dependencies, or configuration files.
  • ci: Changes to CI/CD configuration (GitHub Actions, Jenkins, etc.).
  • chore: Maintenance tasks that don't modify source or test files.
  • revert: Reverting a previous commit.

Best Practices

  • Use imperative mood: Write "add feature" not "added feature" or "adds feature".
  • Keep it concise: Description should be 50 characters or less when possible.
  • Add scope when relevant: Specify the component or module affected (e.g., "auth", "api", "ui").
  • Explain the why: Use the body to explain what and why, not how (the code shows how).
  • Reference issues: Use footer to close issues (e.g., "Closes #123") or indicate breaking changes.
  • Breaking changes: Use "BREAKING CHANGE:" in footer for changes that break backward compatibility.

Example Commit Messages

feat(auth): add OAuth2 login support

Implement Google and GitHub OAuth2 authentication.
Allows users to sign in with external accounts.

Closes #123

---

fix(api): resolve null pointer exception in user endpoint

Handle null user data gracefully and return proper error response.

Fixes #456

---

docs(readme): update installation instructions

Add Node.js version requirement and Docker setup steps.

---

refactor(utils): extract validation logic into separate module

Improve code organization and reusability.

Integration with Tools

Conventional commits work seamlessly with popular tools:

  • Semantic Versioning: Automatically determine version bumps based on commit types.
  • Changelog Generators: Tools like standard-version and semantic-release generate changelogs automatically.
  • Git Hooks: Use commit-msg hooks to validate commit message format.
  • CI/CD: Automate releases based on commit message patterns.

Frequently asked questions

What is the Conventional Commits specification?

Conventional Commits is a specification for commit messages that provides a standardized format. It helps maintain consistent commit history, enables automated versioning, and makes it easier to generate changelogs. The format is: type(scope): description, followed by optional body and footer.

What are the most common commit types?

The most common types are: feat (new feature), fix (bug fix), docs (documentation), style (formatting), refactor (code restructuring), perf (performance), test (tests), build (build system), ci (CI/CD), chore (maintenance), and revert (revert commit).

Should I use emoji in commit messages?

Emoji in commit messages are optional and primarily for visual clarity. Some teams prefer them for quick scanning, while others prefer text-only for better parsing by automated tools. Choose based on your team's preferences and tooling requirements.

What is a commit scope?

A scope is an optional part of the commit message that specifies the component or module affected by the change. Examples include 'auth', 'api', 'ui', 'database'. It helps organize commits and makes it easier to filter commit history by component.

How do I indicate breaking changes?

Breaking changes should be indicated in the footer of the commit message using 'BREAKING CHANGE:' followed by a description. Alternatively, you can add an exclamation mark after the type/scope (e.g., 'feat!:' or 'feat(api)!:'). Breaking changes typically trigger a major version bump in semantic versioning.

Can I use this tool offline?

This tool works entirely in your browser using JavaScript. All processing happens client-side, so your commit messages are never sent to any server. You can use it offline if you have the page cached, though an internet connection is needed to load the page initially.