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

3.0 KiB
Raw Blame History

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

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

Язык

  • Язык коммитов: русский.
  • Технические термины (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

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

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

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

<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