Skip to main content
This guide MUST be followed for all commits across HandaUncle repositories. Non-compliant commits may be rejected during code review.
This document explains the commit message format used across all repositories. Following this standard ensures:
  • Clean and searchable commit history
  • Automatic changelog generation
  • Semantic versioning (major/minor/patch)
  • Clear communication across teams
  • Automated SDK publishing + CI pipelines

Commit Message Format

Every commit follows this structure:

Commit Types (Prefixes)

Below is the complete list of prefixes used in modern engineering teams.

βœ… feat β€” New Feature

Used when adding new capabilities, endpoints, UI elements, models, or SDK methods.
Triggers minor version bump (1.2.0 β†’ 1.3.0)

🐞 fix β€” Bug Fix

Used when fixing incorrect behavior, broken logic, bad types, crashes, or regressions.
Triggers patch version bump (1.3.1 β†’ 1.3.2)

πŸ”§ chore β€” Maintenance Tasks

Used for changes that do not affect functionality.
Does not affect versioning

πŸ” refactor β€” Internal Code Improvements

Used when changing code structure without altering behavior.
Does not bump version

πŸ“š docs β€” Documentation Only

Used for changes to documentation, comments, or examples.

🎨 style β€” Code Style Changes

Used for formatting, styling, lint fixes, or naming improvements.

πŸ§ͺ test β€” Adding or Modifying Tests

Used when creating or fixing tests.

βš™οΈ build β€” Build System Changes

Used for changes in the build pipeline, bundlers, tooling, dependencies, or configuration.

πŸ› οΈ ci β€” Continuous Integration

Used for changes to GitHub Actions, pipelines, scripts, and automation.

πŸš€ perf β€” Performance Improvements

Used when improving performance, reducing latency, or optimizing code.

πŸ”’ security β€” Security Fixes

Used when correcting vulnerabilities or implementing secure patterns.

↩️ revert β€” Reverting a Commit

Automatically created by Git when rolling back a previous change.

Using Scopes

Scopes clarify where the change happened. Format:

Breaking Changes

Breaking changes must be indicated clearly by adding ! after the type or scope.
Format options:
Additionally, the commit must contain a footer:
Triggers a major version bump (1.3.2 β†’ 2.0.0)

Commit Body (Optional)

Used when you need to provide more context.

Used for:
  • Breaking changes
  • Issue linking
  • Migration notes
  • Deprecations

Full Examples


Best Practices

Keep Subject Short

Subject line should be under 72 characters

Use Imperative Tone

Use β€œadd”, β€œfix” β€” not β€œadding”, β€œfixed”

Include Scopes

Add scopes whenever possible for clarity

Single Purpose

Never mix unrelated changes in one commit

Commit Template

Copy this template and save it as .gitmessage in your home directory, then run: