Skip to content

Instantly share code, notes, and snippets.

@tildebyte
Created December 13, 2025 03:21
Show Gist options
  • Select an option

  • Save tildebyte/ebcf0a27701ba9fb63b1e4f8a28905e7 to your computer and use it in GitHub Desktop.

Select an option

Save tildebyte/ebcf0a27701ba9fb63b1e4f8a28905e7 to your computer and use it in GitHub Desktop.
Conventional commit reference for humans and agents

Conventional commits

Generally

  • all lower-case
  • no terminal periods
  • wrap lines at 78 chars (this means that the description must either fit into 78 chars, or use '...' to indicate continuation into the first line of the body)

Format

type(scope, other scope)!: description

[optional body]

Signed-off-by: foo@bar-baz.com
[optional-footer]

TYPE

  • feat : A new feature
  • fix : A bug fix
  • secure : A verified fix for security issues of any kind
  • perf : A code change that improves performance
  • refactor : A change to existing code which neither fixes a bug nor adds a feature
  • docs : Docs-only changes
  • test : Adding missing tests or correcting existing tests
  • chore : tech-debt
  • agent : agent-related changes (AGENTS.md, commands, skills, "agent-notes" dir)
  • build : Changes that affect the build system or external dependencies : (example SCOPES: gulp, broccoli, npm)
  • ci : Changes to CI configuration files and scripts (example SCOPES: : Travis, Circle, BrowserStack, SauceLabs)
  • repo : .gitignore; git options; folder/file reorg; etc.
  • style : Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • revert : ONLY IN CASE OF EMERGENCIES, AND ONLY ON PROTECTED BRANCHES Don't make revert commits on your private topic branch; rebase instead

SCOPE

  • should be the name of the affected package/module (e.g.: 'auth', 'api', 'cli', 'db', 'deps' etc.)
  • exceptions
    • packaging
    • changelog: used for updating the release notes
    • none/empty string: useful for style, test and refactor changes that are done across all packages (e.g. style: add missing semicolons)

BREAKING CHANGE

Indicated by any or all of

  • TYPE(SCOPE)!: DESCRIPTION # (add '!')
  • (in FOOTER)
    • BREAKING CHANGE: info

DESCRIPTION

User-facing impact (max 70 chars, lowercase, no period)

BODY

Rationale for non-obvious changes (blank line separator)

FOOTER

Footer always looks like e.g. (all are are optional except "Signed-off-by")

to follow git trailer convention

Signed-off-by

Always use the -s / --signoff flag when committing:

git commit -s -m "feat(auth): add token validation"

This automatically adds "Signed-off-by: " using configured git config credentials (see git docs for setup).

Always manually add signoff lines if missing. Rebase after but only in un-pushed topic branches

Examples

Good

fix(odcs): because ODCS results are now sorted

specifically fixes 'test_ignore_missing_content_sets'

- Closes #914

Signed-off-by: Ben Alkov <ben.alkov@redhat.com>
toil(env): unify/clarify/normalize markers/envs in tox/environment configs

- CLOUDBLD-2734

Signed-off-by: Ben Alkov <ben.alkov@redhat.com>

Avoid

  • File/function names
  • implementation details
  • Praise adjectives (comprehensive, best)
  • Vague descriptions (updated the code, fixed the bug)
  • Change process verbs (added, changed, updated)

Commit philosophy

A commit represents a logical unit when

  • All changes serve a single, coherent purpose
  • The change can be described in one clear commit message
  • Reverting the commit wouldn't leave codebase broken
  • Changes are related by causation, not just timing

Create separate commits when

  • Changes address unrelated issues
  • Functional change mixed with unrelated refactoring
  • Changes affect independent modules
  • One change is ready, another needs more work

Single commit acceptable when

  • Refactoring requires updating related tests and documentation
  • Bug fix requires both implementation and regression test
  • New feature requires implementation and integration tests

Merge Order

Merge commits intelligently by type priority (fix > feat > perf > refactor > docs > test > chore > all others)

If commits aren't in priority order, it's OK to rebase them but only in un-pushed topic branches

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment