STD-PROC-003 · Conventional Commits¶

1. Cel¶

Ujednolicić komunikaty commitów tak, by historia była czytelna dla ludzi i przetwarzalna maszynowo (automatyczne wersjonowanie i changelog).

2. Zakres¶

Dotyczy komunikatów trafiających na gałęzie współdzielone — tytułu MR, komunikatu squasha lub merge commita. Nie dotyczy lokalnych, roboczych commitów przed scaleniem.

3. Wymagania (normatywne)¶

R1. Komunikat MUSI być zgodny ze specyfikacją Conventional Commits 1.0.0 w formacie typ(zakres)!: opis.
R2. Typ MUSI należeć do listy dozwolonych typów ustalonej przez organizację.
R3. Zmiana łamiąca zgodność MUSI być oznaczona — znakiem ! po typie/zakresie albo stopką BREAKING CHANGE:.
R4. Opis POWINIEN być zwięzły, w trybie rozkazującym, bez kropki na końcu.
R5. Zakres (scope) MOŻE wskazywać obszar zmiany.

4. Minimum of Done¶

Czy komunikaty commitów są zgodne z formatem Conventional Commits?
Czy użyte typy należą do listy dozwolonej?
Czy lista dozwolonych typów jest udokumentowana w repo? (manual)

Weryfikacja: bash standards/proces/STD-PROC-003/bin/checks.sh

5. Implementacja — dobra praktyka (informacyjne, niewiążące)¶

Walidacja przez commitlint z @commitlint/config-conventional, lista typów: feat, fix, docs, refactor, test, build, ci, chore, perf. Lokalnie hook (husky / pre-commit) dla szybkiej informacji zwrotnej, w CI job lintujący dla pewności. Powiązanie z wersjonowaniem: feat → minor, fix → patch, BREAKING CHANGE → major.

commitlint:
  stage: lint
  script:
    - npx commitlint --from "$CI_MERGE_REQUEST_DIFF_BASE_SHA" --to HEAD
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

Przykłady — dobrze: feat(auth): dodaj logowanie przez OIDC · breaking: feat(api)!: usuń endpoint /v1. Źle: update, WIP, poprawki.

6. Referencje¶

conventionalcommits.org (spec 1.0.0) · STD-PROC-002 Strategia gałęzienia · STD-PROC-004 Zarządzanie wydaniami.