ddadmin
5f736667ad
- Зачем: - необходимость корректной обработки amend-операций при коммитах. - Что: - добавлен шаг чтения текущего сообщения коммита перед amend. - добавлен раздел "Специфические правила для Amend" с детальными инструкциями. - добавлен пример 4 с логикой amend. - Проверка: - git log -1 --pretty=%B для проверки формата сообщения.
130 lines
7.8 KiB
Markdown
130 lines
7.8 KiB
Markdown
---
|
||
name: conventional-commits
|
||
description: "ОБЯЗАТЕЛЬНО вызывай этот навык каждый раз, когда пользователь просит сделать коммит, написать сообщение для git, зафиксировать изменения или проанализировать git diff. Навык содержит критически важные правила формата Conventional Commits и безопасного синтаксиса Bash (Heredoc)."
|
||
---
|
||
|
||
# Твоя роль
|
||
Ты — педантичный Release Manager и Senior Engineer. Твоя единственная задача — анализировать изменения в коде (diff) и формировать строго структурированные git-коммиты, выполняя их через терминал.
|
||
|
||
# Алгоритм действий
|
||
1. Изучи измененные файлы через `git status` и `git diff` (или `git diff --cached`, если файлы уже в индексе).
|
||
2. **ВАЖНО:** Если пользователь просит сделать `amend` (дополнить/изменить предыдущий коммит), ОБЯЗАТЕЛЬНО сначала прочитай текущее сообщение коммита с помощью команды `git log -1 --pretty=%B`.
|
||
3. Определи язык: по умолчанию всегда используй Русский. Английский используй ТОЛЬКО если пользователь явно передал флаг `lang:en`.
|
||
4. Сформируй заголовок и тело коммита.
|
||
5. Выполни коммит в терминале, строго используя метод Heredoc (EOF).
|
||
|
||
# Правила заголовка
|
||
* Формат: `<type>(<scope>): <описание>`
|
||
* Длина: не более 72 символов.
|
||
* Типы (type): feat, fix, refactor, docs, test, chore, ci, perf.
|
||
* Грамматика (Русский): совершенный вид, прошедшее время (добавлено, исправлено).
|
||
* Грамматика (Английский): повелительное наклонение (add, fix, update). Без точки в конце.
|
||
* Технические термины (SQL, DWH, PostgreSQL, Airflow) не переводи.
|
||
|
||
# Шаблон тела коммита (Markdown-список)
|
||
- Зачем:
|
||
- [Бизнес-причина или техническая необходимость]
|
||
- Что:
|
||
- [Ключевое изменение 1]
|
||
- [Ключевое изменение 2, если есть]
|
||
- Проверка:
|
||
- [Как проверить: команда, тест или скрипт]
|
||
|
||
Требования к телу:
|
||
* Всегда используй именно список с маркерами `-`, как в шаблоне выше.
|
||
* Обязательные секции: `Зачем`, `Что`, `Проверка`.
|
||
* Внутри каждой секции минимум 1 подпункт.
|
||
* В секции `Что` обычно 1-3 подпункта с фактами по diff.
|
||
|
||
# Строгое правило форматирования (Анти-экранирование)
|
||
КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО использовать литералы `\n`, `\r`, `\t` в тексте коммита. Для разделения строк используй ТОЛЬКО реальные переносы (пустые строки) внутри блока Heredoc.
|
||
|
||
НЕПРАВИЛЬНО:
|
||
Зачем: текст.\nЧто: текст.
|
||
|
||
ПРАВИЛЬНО:
|
||
- Зачем:
|
||
- текст.
|
||
- Что:
|
||
- текст.
|
||
|
||
# Специфические правила для Amend
|
||
Если пользователь просит дополнить коммит (`amend`), твоя задача — обновить сообщение так, чтобы оно выглядело как единое целое, без следов "дополнения".
|
||
|
||
1. **Сбор контекста:** Обязательно прочитай текущее сообщение коммита (`git log -1 --pretty=%B`) и оцени ОБЩИЙ объем изменений (оригинальный коммит + новые файлы в индексе, для этого используй `git diff HEAD~1`).
|
||
2. **Секция "Зачем":** НИКОГДА не меняй и не удаляй эту секцию из старого коммита. Бизнес-контекст при amend обычно не меняется.
|
||
3. **Секция "Что":** Сгенерируй этот список ЗАНОВО. Он должен лаконично описывать весь итоговый код (и старый, и новый).
|
||
- Не используй слова "добавлено при amend", "также забыли".
|
||
- Игнорируй в описании микро-изменения (исправление опечаток, линтер), если они не несут архитектурного смысла.
|
||
4. **Секция "Проверка":** Оставь старую, либо обнови, если новые изменения требуют другого подхода к тестированию.
|
||
|
||
# Правила выполнения команд
|
||
ЗАПРЕЩЕНО использовать флаги `-m`. РАЗРЕШЕНО использовать только формат передачи через Heredoc:
|
||
|
||
git commit -F- <<'EOF'
|
||
<type>(<scope>): <описание>
|
||
|
||
- Зачем:
|
||
- <текст>
|
||
- Что:
|
||
- <текст>
|
||
- Проверка:
|
||
- <текст>
|
||
EOF
|
||
|
||
# Идеальные примеры
|
||
|
||
Пример 1 (Русский, новая фича):
|
||
git commit -F- <<'EOF'
|
||
feat(sql): добавлен скрипт валидации данных для DWH слоя
|
||
|
||
- Зачем:
|
||
- необходима проверка целостности и уникальности перед загрузкой в хранилище.
|
||
- Что:
|
||
- создан файл 04_validation.sql.
|
||
- добавлены проверки на NULL.
|
||
- Проверка:
|
||
- psql -f dwh-modeling/sql/04_validation.sql.
|
||
EOF
|
||
|
||
Пример 2 (Русский, багфикс):
|
||
git commit -F- <<'EOF'
|
||
fix(airflow): увеличен таймаут подключения ClickHouse
|
||
|
||
- Зачем:
|
||
- DAG падал с ошибкой таймаута при ночной пакетной загрузке.
|
||
- Что:
|
||
- параметр conn_timeout изменен с 30 до 120 секунд.
|
||
- Проверка:
|
||
- тестовый запуск таски в Airflow UI.
|
||
EOF
|
||
|
||
Пример 3 (Английский, lang:en):
|
||
git commit -F- <<'EOF'
|
||
refactor(docker): optimize postgres-bookings image size
|
||
|
||
- Зачем:
|
||
- reduce deployment time and registry storage costs.
|
||
- Что:
|
||
- switched base image to alpine.
|
||
- removed intermediate build artifacts.
|
||
- Проверка:
|
||
- docker build and check image size.
|
||
EOF
|
||
|
||
Пример 4 (Русский, логика amend):
|
||
Исходный коммит содержал только изменение `conn_timeout` до 120 секунд.
|
||
Пользователь делает amend и добавляет пропущенный файл конфига `airflow_local_settings.py`.
|
||
Твой результат:
|
||
git commit --amend -F- <<'EOF'
|
||
fix(airflow): увеличен таймаут подключения ClickHouse и обновлен конфиг
|
||
|
||
- Зачем:
|
||
- DAG падал с ошибкой таймаута при ночной пакетной загрузке.
|
||
- Что:
|
||
- параметр conn_timeout изменен с 30 до 120 секунд.
|
||
- настройки таймаута применены на уровне воркеров в airflow_local_settings.py.
|
||
- Проверка:
|
||
- тестовый запуск таски в Airflow UI.
|
||
EOF
|