backend-api/COMMIT_CONVENTION.md

3.1 KiB

Commit Message Convention

This project follows the Conventional Commits specification (v1.0.0). This leads to more readable messages that are easier to follow when looking through the project history and allows for automated changelog generation.

Reference: https://www.conventionalcommits.org/

Format

Each commit message consists of a header, a body and a footer.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Header

The header is mandatory and includes a type, an optional scope, and a description.

<type>

This describes the kind of change that this commit is providing. Must be one of the following:

  • feat: A new feature
  • fix: A bug fix
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests
  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
  • docs: Documentation only changes
  • chore: Other changes that don't modify src or test files (e.g., updating dependencies, project config)
  • revert: Reverts a previous commit

<scope> (Optional)

The scope provides contextual information to the commit type. It's contained within parentheses, e.g., feat(api): ... or fix(ui): .... Choose a scope that represents the area of the codebase affected (e.g., auth, map, pipeline, worker, deps, config, ci, ui, docs).

<description>

A short summary of the code changes.

  • Use the imperative, present tense: "change" not "changed" nor "changes".
  • Don't capitalize the first letter.
  • No dot (.) at the end.

Body (Optional)

The body should include the motivation for the change and contrast this with previous behavior. Use the imperative, present tense.

Footer(s) (Optional)

  • Breaking Changes: Start with BREAKING CHANGE: followed by a description of the breaking change.
  • Referencing Issues: Use keywords like Closes #123, Fixes #456.

Examples

feat: add user authentication endpoint
fix(api): correct pagination logic for pipelines endpoint

The previous implementation did not handle the offset correctly,
causing duplicate items on subsequent pages.
refactor(map): extract overlay management into separate context

Improves separation of concerns and makes the map component cleaner.
chore(deps): update FastAPI to version 0.100.0
test(crud): add unit tests for pipeline run creation
docs: update README with deployment instructions
feat(ui)!: replace Button component with new design system button

BREAKING CHANGE: The `variant` prop for Button components has changed.
Refer to the updated design system documentation. Closes #78