Files
clickstream-ch-kafka-supers…/docs/COMMIT_RULES.md
T
ddadmin 60cb20406f docs(docs): добавить правила оформления коммитов
- Зачем:
  - унифицировать стиль коммитов для всех участников проекта
- Что сделано:
  - добавлен документ docs/COMMIT_RULES.md с форматом и примерами
  - добавлена ссылка на правила в AGENTS.md
- Проверка:
  - проверен staged diff перед коммитом
2026-02-08 16:42:43 +03:00

79 lines
3.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Правила оформления коммитов
Документ задаёт единый стиль коммитов для всех участников проекта.
## Язык
- Язык коммитов: русский.
- Технические термины (`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`