Почему писать коммиты — самое скучное занятие на свете
Вы только что закончили фичу. Три часа кодинга, дебаггинга, тестирования. Осталось сделать последний шаг — закоммитить изменения. И вот тут начинается мучение. Что написать в сообщении? «Исправил баг»? «Добавил фичу»? «Оптимизировал производительность»? Вы тратите пять минут, пытаясь сформулировать что-то осмысленное, в итоге пишете «фикс» и чувствуете себя неудачником.
Проблема не в лени. Проблема в контекстном переключении. Ваш мозг только что работал в режиме разработчика — анализировал код, искал решения, писал логику. Теперь ему нужно переключиться в режим технического писателя — кратко, точно, понятно описать изменения. Это как после марафона сесть писать диссертацию.
Худший коммит, который я видел в продакшене: «что-то сделал, не помню что». Автор честно признался в своем бессилии.
gsh: когда shell начинает думать за вас
Есть инструмент, который решает эту проблему радикально. Не через плагины для IDE, не через веб-интерфейсы, а прямо в терминале. gsh — это shell, который умеет вызывать локальную LLM для автодополнения команд. В том числе git-команд.
Представьте: вы пишете git commit -m и нажимаете Tab. Shell анализирует ваш git diff, отправляет его в локально запущенную модель (никаких облаков, никаких API-ключей) и предлагает готовое сообщение коммита. Вы либо принимаете его, либо правите. Весь процесс занимает секунды.
Что нужно для работы
- Локально запущенная LLM с OpenAI-совместимым API эндпоинтом
- Установленный gsh (просто клонируйте репозиторий)
- Базовое понимание, как работает git diff
- Желание перестать тратить время на рутину
1Выбираем модель: не все LLM одинаково полезны
Первое, что ломает новичков — выбор модели. Берут первую попавшуюся из списка «лучших моделей для кодинга», запускают, получают ерунду. Потому что для анализа git diff нужны специфические способности.
| Модель | Почему работает | Минусы |
|---|---|---|
| Qwen2.5-Coder-7B | Специализирована на коде, понимает контекст изменений | Требует 8+ GB RAM |
| DeepSeek-Coder-V2-Lite | Отлично работает с diff, дает структурированные ответы | Медленнее на слабом железе |
| Codestral-22B | Французская модель, но для коммитов подходит идеально | Очень требовательна к ресурсам |
Лично я остановился на Qwen2.5-Coder-7B-Instruct. Она достаточно легкая для локального запуска (если у вас есть статья про скачивание моделей в GGUF, там похожий процесс).
2Настраиваем gsh: не просто установка, а интеграция
Установка gsh тривиальна: клонируете репозиторий, добавляете в PATH. Но интеграция с локальной LLM — вот где собака зарыта.
- Запускаем Ollama с нужной моделью:
ollama run qwen2.5-coder:7b - Проверяем, что API доступен на http://localhost:11434/v1
- В конфиге gsh прописываем этот эндпоинт
- Настраиваем промпт для git commit (об этом ниже)
Самый частый косяк: забыть указать модель в запросе к API. Ollama по умолчанию может использовать другую модель, и тогда вы получите коммиты про философию Ницше вместо исправления бага.
3Промпт — это всё
Без правильно написанного промпта даже самая умная модель будет генерировать мусор. Промпт для автодополнения коммитов должен решать три задачи:
- Анализировать diff и понимать, что именно изменилось
- Формулировать кратко, но информативно
- Следовать соглашениям вашей команды (если они есть)
Вот базовый промпт, который работает в 80% случаев:
Ты — ассистент для написания сообщений git commit. Проанализируй предоставленный git diff и предложи краткое, информативное сообщение коммита. Сообщение должно:
1. Начинаться с глагола в повелительном наклонении (исправь, добавь, обнови)
2. Быть не длиннее 50 символов
3. Точно отражать суть изменений
4. Избегать общих фраз вроде «небольшие правки»
Git diff:
{diff}
Но это только начало. Настоящая магия начинается, когда вы добавляете контекст проекта.
Продвинутые промпты: от базовых к персональным
Базовый промпт дает приемлемый результат. Но если хотите, чтобы коммиты звучали так, будто их писали вы (а не случайный ИИ), нужно кастомизировать.
Добавляем контекст проекта
Представьте, что вы работаете над бэкендом на Go. Ваши коммиты про «исправил ошибку» выглядят непрофессионально. Добавьте в промпт информацию о проекте:
Проект: бэкенд сервиса на Go, использует PostgreSQL и Redis. Мы следуем соглашениям:
- Сообщения коммитов на английском
- Первое слово — глагол (fix, add, update, refactor)
- Если коммит связан с API, указываем endpoint
- Если коммит связан с БД, указываем таблицу
Проанализируй diff и предложи сообщение.
Теперь вместо «fix bug» вы получите «fix: incorrect user_id validation in /api/v1/users endpoint».
Специфичные промпты для разных типов изменений
Один промпт на все случаи жизни — плохая идея. Настройте разные промпты для:
- Фич (новый функционал)
- Багов (исправления)
- Рефакторинга (изменения структуры без изменения поведения)
- Документации
Для этого в gsh можно настроить разные команды или использовать условие в промпте, анализируя diff.
Практический пример: от diff до идеального коммита
Допустим, вы исправили баг в аутентификации. Ваш git diff показывает изменения в файле auth.py. Вы запускаете автодополнение через gsh.
Модель получает diff, анализирует его с помощью промпта и предлагает: «fix: prevent null pointer exception in JWT token validation».
Вы смотрите, киваете (или правите пару слов) и коммитите. Весь процесс занял 3 секунды вместо 3 минут умственного напряжения.
Ошибки, которые все совершают (и как их избежать)
| Ошибка | Почему происходит | Как исправить |
|---|---|---|
| Модель генерирует слишком общие коммиты | Промпт не содержит достаточно контекста или ограничений | Добавить в промпт конкретные требования к формату |
| Коммиты не соответствуют стилю команды | Не учтены соглашения проекта | Включить правила команды в промпт |
| Долгое время ответа | Слишком большая модель или слабое железо | Использовать более легкие модели (7B вместо 13B) |
| Некорректный анализ diff | Модель не специализирована на коде | Перейти на код-специфичные модели (Qwen Coder, DeepSeek Coder) |
Интеграция в рабочий процесс: больше чем просто коммиты
Когда вы настроили автодополнение коммитов, появляется соблазн автоматизировать всё подряд. И это правильно.
gsh умеет не только с git работать. С его помощью можно:
- Генерировать команды Docker по описанию
- Писать сложные find/grep команды
- Формулировать curl-запросы к API
- Даже объяснять ошибки, которые вы видите в логах
Это превращает терминал из инструмента для ввода команд в интеллектуального помощника. Как в статье про gsh и умный терминал, только с фокусом на разработку.
Будущее: когда ИИ пишет всю историю проекта
Сейчас мы автоматизируем написание сообщений коммитов. Завтра можно будет автоматизировать:
- Генерацию changelog из истории коммитов
- Написание Pull Request описаний
- Автоматическую категоризацию коммитов (feat, fix, docs и т.д.)
- Поиск связанных коммитов при анализе багов
Локальная LLM в этом сценарии идеальна — все ваши изменения остаются на вашем компьютере, никаких утечек в облако, никаких проблем с compliance в корпоративных проектах.
Важный нюанс: если вы работаете с закрытым кодом или в регулируемой индустрии (финансы, медицина), локальная LLM — не просто удобство, а требование безопасности.
Что делать, если не работает
Бывает. LLM — не детерминированная система. Иногда она выдает ерунду. Алгоритм действий:
- Проверьте, что модель действительно запущена и отвечает на запросы
- Убедитесь, что в промпте нет опечаток или противоречивых инструкций
- Попробуйте упростить промпт — иногда меньше значит лучше
- Если модель постоянно ошибается с конкретным типом изменений — создайте отдельный промпт для этого случая
И главное — не ожидайте совершенства с первого раза. Настройка промптов это итеративный процесс. Вы корректируете, модель учится, вы снова корректируете.
Итог: стоит ли игра свеч?
Абсолютно. Даже если вы сэкономите всего 2 минуты на коммит, при 5 коммитах в день это 10 минут в день. 50 минут в неделю. Более 40 часов в год. Целую рабочую неделю, которую вы тратили на рутину.
Но ценность не только во времени. Ценность в качестве. Ваша история коммитов перестает быть набором случайных фраз и становится документацией проекта. Новый разработчик, присоединившись к команде, сможет понять логику изменений. Вы сами, вернувшись к коду через полгода, не будете гадать, что значит «fix stuff».
Начинайте с простого: установите gsh, запустите любую код-модель через Ollama, настройте базовый промпт. Первый же коммит, сгенерированный ИИ, убедит вас, что игра стоит свеч.
А потом, когда привыкнете, попробуйте автоматизировать что-то еще. Терминал — это новая IDE. И ИИ — ваш новый pair programmer.
