# Git Conventional Commit > Формирует commit-сообщение по Conventional Commits для текущих изменений в git. Анализирует staged-diff (или unstaged, если staged пуст), определяет type/scope, пишет subject и при необходимости тело. Используй, когда пользователь хочет «сделать коммит», «закоммитить изменения», «commit это», «сформулируй commit-message», «commit по конвенции». - Skill: `jtprogru/git-conventional-commit` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add jtprogru/git-conventional-commit` - Raw SKILL.md: https://api.skillmd.com/api/skills/jtprogru/git-conventional-commit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: jtprogru (https://skillmd.com/u/jtprogru) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jtprogru/git-conventional-commit --- # git-conventional-commit — Conventional Commit message для текущего diff Цель: вместо того чтобы пользователь сам формулировал commit-message, ты анализируешь diff и формируешь сообщение по конвенции `../../rules/git-conventions.md`. Перед началом прочитай `../../rules/git-conventions.md` — там полный список допустимых `type`, формат scope и принципы. ## Шаг 1. Собери контекст Запусти: - `git status --short` — посмотри, что изменено - `git diff --staged` (если есть staged) или `git diff` (если нет) — содержание изменений - `git log --oneline -10` — стиль предыдущих коммитов в проекте (особенно язык: русский/английский) Если staged пуст и unstaged тоже — скажи пользователю и остановись. ## Шаг 2. Определи type Прочитай diff и реши: | diff показывает | type | |----------------|------| | новый файл с функциональностью, новый endpoint, новая фича | `feat` | | правка логики, чтобы баг перестал воспроизводиться | `fix` | | перенос/переименование/упрощение без изменения поведения | `refactor` | | только улучшение производительности | `perf` | | только `.md`, комментарии в коде | `docs` | | только тесты добавлены или поправлены | `test` | | `package.json`, `go.mod`, `requirements.txt`, Dockerfile, CI-конфиги | `build` или `ci` | | зависимости, версии тулинга | `chore(deps)` | | откат предыдущего коммита | `revert` | Если diff смешанный (например, и `fix` и `refactor`) — **остановись и предложи пользователю разбить на несколько коммитов**. Не пиши «feat: исправил баг и отрефакторил» — это анти-паттерн. ## Шаг 3. Определи scope (опционально) Scope — короткое имя модуля/папки/SDK. Эвристика: - если все файлы под одной папкой первого уровня (`src/auth/`, `sdk-go/`, `cli/`) — scope = имя этой папки - если затронуто 2-3 файла в разных папках — scope можно опустить - если поправлен один конкретный компонент (`UserCard.tsx`) — scope = имя компонента в kebab-case ## Шаг 4. Сформулируй subject - 50-72 символа - глагол в настоящем времени, без заглавной буквы, без точки - если коммиты в проекте на русском — пиши на русском, если на английском — на английском (смотри `git log`) - субъект описывает **что изменилось**, не «что я сделал» Плохо: `feat: добавил новый эндпоинт для логина пользователей` Хорошо: `feat(auth): добавить endpoint POST /login` ## Шаг 5. Тело и футер (если нужны) Тело пиши, если: - изменение неочевидно из subject — объясни **зачем** - есть breaking change — обязательно - есть ссылки на issue/тикет Формат: ``` (): BREAKING CHANGE: <что ломается и как мигрировать> Refs: #123 ``` ## Шаг 6. Покажи и спроси Покажи пользователю предложенный commit-message в блоке. Спроси: 1. Принять как есть → `git commit -m "..."` 2. Поправить subject/тело 3. Разбить на несколько коммитов 4. Отменить **Не запускай `git commit` без подтверждения пользователя.** ## Шаг 7. Выполни После подтверждения: - если subject короткий (одностроковый) — `git commit -m "..."` - если есть тело — используй `git commit -F -` с heredoc, либо временный файл Покажи результат `git log -1 --stat`. ## Чего не делать - Не предлагай `chore: update` — это пустое сообщение - Не объединяй несвязанные изменения в один коммит - Не используй `feat` для багфиксов и наоборот - Не пиши «WIP» в финальном коммите — для WIP есть `git commit --fixup` и rebase позже