# Правила оформления коммитов

Документ задаёт единый стиль коммитов для всех участников проекта.

## Язык

- Язык коммитов: русский.
- Технические термины (`Airflow`, `ClickHouse`, `Kafka`, `MV`, `DDL`) допускаются на английском.

## Формат заголовка

- Формат: `<type>(<scope>): <краткое действие>`
- Максимальная длина заголовка: 72 символа.
- Заголовок пишется в повелительном стиле, без точки в конце.

### Разрешённые `type`

- `feat` — новая функциональность
- `fix` — исправление ошибки
- `refactor` — изменение структуры без смены поведения
- `docs` — документация
- `test` — тесты/проверки
- `chore` — сервисные изменения (конфиги, скрипты, хуки)
- `ci` — CI/CD
- `perf` — оптимизация производительности
- `revert` — откат коммита

### Рекомендуемые `scope` для этого репозитория

- `airflow`
- `stg`
- `ods`
- `dds`
- `dm`
- `kafka`
- `superset`
- `monitoring`
- `scripts`
- `docs`
- `infra`

## Структура тела коммита

Если изменение не тривиальное, тело коммита обязательно. Для удобства чтения используйте буллеты.

Рекомендуемый шаблон:

```text
<type>(<scope>): <краткое действие>

- Зачем:
  - причина изменения
- Что сделано:
  - ключевое изменение 1
  - ключевое изменение 2
- Проверка:
  - как проверено (команда/тест/смоук-чек)
```

## Размер и границы коммита

- Один коммит = одна логическая задача.
- Не смешивать в одном коммите функциональные изменения и крупный рефакторинг без необходимости.
- Документацию обновлять в том же коммите, где меняется поведение пайплайна или инфраструктуры.

## Ломающие изменения

- Для ломающих изменений используйте `!` в заголовке:
  - `feat(ods)!: изменить контракт таблицы browser_event`
- Добавляйте footer:
  - `BREAKING CHANGE: ...`

## Примеры

- `feat(ods): перенести STG->ODS в batch шаг Airflow`
- `fix(airflow): ждать данные в STG перед load_ods`
- `docs(architecture): обновить схему потока после миграции ODS`
- `chore(scripts): синхронизировать make transform с новым ETL`