- Зачем: - унифицировать стиль коммитов для всех участников проекта - Что сделано: - добавлен документ docs/COMMIT_RULES.md с форматом и примерами - добавлена ссылка на правила в AGENTS.md - Проверка: - проверен staged diff перед коммитом
79 lines
3.0 KiB
Markdown
79 lines
3.0 KiB
Markdown
# Правила оформления коммитов
|
||
|
||
Документ задаёт единый стиль коммитов для всех участников проекта.
|
||
|
||
## Язык
|
||
|
||
- Язык коммитов: русский.
|
||
- Технические термины (`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`
|