Git commit planner

Git Commit Planner

Анализирует изменения в git-репозитории и строит структурированный план логических атомарных коммитов вместо одного большого монолитного коммита.

Когда применять

• В репозитории много незакоммиченных изменений в разных файлах/модулях
• Пользователь просит «закоммить изменения» или «организуй коммиты»
• Нужно разбить крупные изменения на логические группы
• Упоминаются «логические коммиты», «атомарные коммиты», отказ от «больших коммитов»

Согласование с git-workflow проекта

Следуй формату коммитов из ~/.claude/CLAUDE.md (git-workflow):

• Conventional Commits, разрешённые типы: feat, fix, refactor, docs, test, chore, perf, ci.
• Формат: <type>: <описание> (опционально со scope: <type>(<scope>): <описание>).
• Описание коммита — на русском языке.
• Attribution отключён глобально — НЕ добавлять Co-Authored-By и подобные трейлеры.

Разрешения на команды

Следующие read-only git-команды выполняются без запроса подтверждения — они безопасны и не меняют состояние репозитория:

• git status / git status --porcelain
• git diff (любые варианты: --stat, --cached, с путями)
• git log (любые варианты: --oneline, -N, с форматированием)
• git ls-files

Процесс анализа

Шаг 1. Анализ состояния репозитория

Запусти эти команды параллельно для сбора информации.

PowerShell (Windows):

git status --porcelain
git ls-files --others --exclude-standard
git log --oneline -10

Bash (Linux/Mac):

git status --porcelain
git ls-files --others --exclude-standard
git log --oneline -10

Коды статуса файлов:

• A — новый файл, staged
• M — изменён, не staged
• M — изменён, staged
• MM — изменён и в staged, и в working directory
• AM — новый файл с дополнительными unstaged-изменениями
• ?? — untracked
• D — удалён, не staged
• D — удалён, staged

Шаг 2. Логическая группировка изменений

Группируй файлы по:

1. Фиче/модулю — изменения одного модуля или фичи
2. Типу изменения — документация, новые фичи, рефакторинг, баг-фиксы, тесты, конфигурация
3. Зависимостям — файлы, которые нужно коммитить вместе
4. Области влияния — инфраструктура, ядро, конкретное приложение, UI

Стратегия планирования коммитов

Порядок приоритета групп

1. Документация и конфигурация — README, docs, конфиги
2. Инфраструктура/ядро — новые системы, крупные рефакторы
3. Новые модули/фичи — целостная новая функциональность
4. Обновления приложений — изменения существующих приложений
5. Тесты — новые или обновлённые
6. Шаблоны и статика — UI-изменения
7. Мелкие фиксы — небольшие правки, чистка

Размер коммита

• Идеально: 5-50 файлов на коммит
• Допустимо: до 100 файлов, если логически связаны
• Избегать: смешивания несвязанных изменений, даже мелких

Формат сообщения коммита

Conventional Commits, описание на русском, без Co-Authored-By:

<type>(<scope>): <краткое описание на русском>

- Деталь 1
- Деталь 2

Разрешённые типы: feat (новая функциональность), fix (исправление бага), refactor (рефакторинг), docs (документация), test (тесты), chore (служебные задачи), perf (производительность), ci (CI/конфигурация сборки).

Формирование плана

Представь план нумерованным списком: номер и заголовок коммита, задействованные файлы (сгруппированы), git-команды, краткое обоснование группировки.

Примеры команд коммита

PowerShell (Windows):

git add file1.py file2.py folder/
git commit -m "feat(module): добавлена новая фича" -m "- Добавлено X" -m "- Обновлены связанные файлы"

Bash (Linux/Mac):

git add file1.py file2.py folder/
git commit -m "feat(module): добавлена новая фича" \
  -m "- Добавлено X" \
  -m "- Обновлены связанные файлы"

Примечание: используй несколько флагов -m вместо heredoc для кросс-платформенной совместимости.

Особые случаи

MM (смешанные изменения): файлы со статусом MM имеют и staged-, и unstaged-изменения. Реши, нужно ли включать unstaged. git add <file> застейджит всё; git restore --staged <file> снимет со стейджа для выборочного добавления.

Удалённые файлы (MD, D ): используй git rm <file> для стейджа удаления.

Untracked (??): определи, нужно ли файл добавить (git add), игнорировать (.gitignore) или удалить с диска.

Большие первые коммиты: при добавлении многих новых файлов (начальные шаблоны, статика) допустимы крупные коммиты. Группируй по функциональным областям (все admin-шаблоны, весь CSS), указывай «initial»/«add» в сообщении.

Типовые паттерны группировки

Django/Python: документация → конфигурация (settings.py, requirements.txt, pyproject.toml) → ядро (новые приложения, базовые классы, утилиты) → отдельные приложения (один коммит на приложение/фичу) → шаблоны по секциям → статика.

JavaScript/Node: конфигурация пакетов (package.json, lock-файлы) → сборка/тулинг (webpack, babel) → исходники по фичам → компоненты по областям → стили и ассеты → тесты.

Анти-паттерны

Не делай: не смешивай документацию с кодом; не объединяй несвязанные фичи; не разделяй логически связанные файлы; не плоди крошечные коммиты для мелких правок одного файла; не включай закомментированный код и debug-вывод.

Делай: держи связанные изменения вместе; пиши понятные сообщения; учитывай будущую code archaeology (когда/зачем изменилось); группируй по принципу «что захочется откатить как единое целое».

Отслеживание прогресса

После каждого коммита: git status --short (проверка), git log --oneline -1 (коммит создан), переход к следующей группе.

Финальная проверка после всех коммитов:

git status              # ожидается "nothing to commit, working tree clean"
git log --oneline -N    # обзор последних N коммитов

Автономное выполнение

ВАЖНО: после того как пользователь одобрил план коммитов, выполняй все коммиты автономно без дополнительных подтверждений. Не спрашивай разрешения на каждую команду git add / git commit — выполняй весь согласованный план последовательно и покажи итоговый результат.

Формат вывода плана

## План коммитов: [Проект]

Найдено [X] изменённых файлов, [Y] новых файлов, [Z] удалённых файлов.

### Коммит 1: Обновление документации
**Файлы:** README.md, docs/api.md, CHANGELOG.md
**Команда:**
git add README.md docs/api.md CHANGELOG.md
git commit -m "docs: обновление документации проекта" -m "- Обновлён README" -m "- Добавлена документация API"

### Коммит 2: Инфраструктура ядра
**Файлы:** src/core/base.py, src/utils/helpers.py
**Команда:**
git add src/core/ src/utils/
git commit -m "refactor(core): улучшение базовых классов и утилит"

[... продолжение для всех коммитов ...]

### Итого
- Запланировано коммитов: [N]
- Файлы сгруппированы по: [стратегия]