commit

name	commit
description	Создание атомарных git commit по правилам проекта - make dev, выбор ID, автоопределение staged/unstaged, группировка и строгий формат сообщений.

Skill: COMMIT

Обзор

Ты - технический лид. Твоя задача: создать чистую историю коммитов.

1. Подготовка (один раз)

Запусти полную проверку проекта один раз перед созданием коммитов:

make dev

Если упало - стой, не коммить и сообщи о проблеме! Не пытайся чинить самостоятельно.

2. Получение номера задачи (ID)

1. Если пользователь указал номер в сообщении (например, "для задачи 16"), используй его.

2. Если номер не указан, ОБЯЗАТЕЛЬНО посмотри последний коммит и возьми ID оттуда:

   git log -1 --oneline
   

3. Определение режима и анализ состояния

Ты должен видеть ВСЕ изменения, включая новые файлы.

Инструменты анализа:

• make dc (или git diff --staged) - смотреть изменения в индексе.
• make d - смотреть изменения в рабочих файлах + НОВЫЕ (untracked) файлы.

Автоопределение режима

Сначала проверь make dc (staged).

Если staged НЕ пуст - делай ОДИН коммит только для staged-изменений. НЕ смотри unstaged, НЕ делай git add. Коммитишь ровно то, что в индексе.

Если staged ПУСТ - переходи к unstaged. Используй СТРОГО make d, чтобы увидеть все изменения (включая контент новых файлов). Разбей изменения на АТОМАРНЫЕ коммиты:

1. Группируй файлы по логике (например: отдельно домен, отдельно тесты, отдельно конфиги).

2. Для каждой группы выполни:

   git add [файлы группы] && git commit -m "#ID - message для этой группы"
   

   Важно: не делай git add ., добавляй только файлы группы.

Если и staged и unstaged ПУСТЫ - СТОП. Сообщи пользователю: "Нет изменений для коммита."

4. Правила сообщения

Формат: #ID - [сообщение]

Пример (правильно):

• #15 - fixed memory leak

Правила стиля:

• Язык: только технический английский.
• Регистр текста: используй строчные буквы (lowercase) для обычных слов.
• Регистр (общий): после двоеточия пишем со строчной буквы, но элементы в списках - с заглавной.
• Регистр кода: СТРОГО сохраняй регистр для имен классов, функций и файлов.
• Время: глаголы СТРОГО в прошедшем времени (added, fixed, refactored).
• Пунктуация: без точек в конце.

Словарь глаголов (используй строго из списка)

✨ New Features (новое)

• added - добавление файла, функции или свойства
• implemented - реализация интерфейса или сложной логики
• introduced - внедрение новой зависимости или системы
• created - создание базовой структуры или компонента

🐛 Bug Fixes (исправления)

• fixed - исправление ошибки, бага или тайпо
• resolved - решение конфликта или логической проблемы
• patched - критическое исправление "на скорую руку"
• handled - добавление обработки ошибок (try/catch)

♻️ Code Improvements (улучшения)

• refactored - реструктуризация кода без изменения поведения
• optimized - улучшение производительности или памяти
• simplified - упрощение сложного куска кода
• standardized - приведение кода к единому стилю

📦 Updates & Maintenance (обновления)

• updated - обновление данных, логики или версий
• upgraded - повышение версии зависимостей
• synced - синхронизация конфигов или типов
• modified - небольшое изменение существующего

🗑 Removal (удаление)

• removed - удаление файлов или кода
• deleted - удаление ресурсов

🎨 UI/UX (внешний вид)

• styled - изменение CSS/SCSS
• aligned - выравнивание элементов
• tweaked - мелкие визуальные правки

ЗАПРЕТЫ

• ⛔️ НЕ запускай make dev перед каждым коммитом, если их несколько - достаточно одного раза в начале.
• ⛔️ НЕ делай один большой коммит, если файлы не в staged. Разделяй.
• ⛔️ НИКАКИХ объяснений и лишнего текста - только команды или сообщение.
• ⛔️ NO git push - КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО.
• ⛔️ NO git reset, git rebase, git commit --amend - ИСТОРИЮ МЕНЯТЬ ЗАПРЕЩЕНО. Только новые коммиты.
• ⛔️ STRICTLY ONLY git commit -m "..." - ИСПОЛЬЗОВАНИЕ ЛЮБЫХ ДРУГИХ ФЛАГОВ ЗАПРЕЩЕНО. Никаких --no-verify, --allow-empty, -n и т.д. Если коммит не проходит (хуки, ошибки) - ОСТАНОВИСЬ и сообщи о проблеме.
• ⛔️ ЗАПРЕЩЕНО добавлять Co-authored-by в сообщение коммита. Только чистый текст в формате #ID - message.