Эта шпаргалка поможет вам быстро и просто составлять сообщения для коммитов, которые соответствуют стандарту Conventional Commits. Она не для обучения или дискуссий о том, нужны ли такие схемы, а служит удобным инструментом?, чтобы подсмотреть и сразу написать коммит.
Если интересно, листайте ниже и пользуйтесь!?
Шаг 1: Выберите тип изменения
В начале сообщения укажите тип, который описывает суть изменений:
feat: Добавление новой функциональности.
fix: Исправление ошибки.
docs: Изменение в документации.
style: Правки по стилю (форматирование, пробелы, запятые и т. д.).
refactor: Рефакторинг кода без исправления ошибок или добавления нового функционала.
perf: Оптимизация производительности.
test: Добавление или обновление тестов.
build: Изменения, касающиеся сборки проекта.
ci: Настройка или изменение CI/CD.
chore: Прочие задачи (например, изменения в .gitignore).
revert: Откат предыдущего коммита.
Пример:
fix(auth): fix token validation issue
Шаг 2: Укажите область изменений (scope, опционально)
Scope помогает уточнить, к какой части проекта относится изменение. Используйте универсальные области, чтобы сразу было понятно, что именно затронуто:
auth: Авторизация и аутентификация.
ui: Пользовательский интерфейс.
api: Серверные или клиентские API.
core: Основной функционал приложения.
config: Файлы конфигурации.
deps: Обновление зависимостей.
tests: Модульные, интеграционные или e2e тесты.
docs: Документация.
db: Изменения в базе данных.
build: Скрипты сборки или сборочные файлы.
Пример:
docs(readme): add installation instructions
Шаг 3: Напишите краткое описание
Описание должно быть коротким и ясным. Вот несколько примеров для вдохновения из разных областей:
UI: "Fix button display on small screens"
API: "Add endpoint for file uploads"
Core: "Optimize cost calculation logic"
Docs: "Update project setup section"
Tests: "Add e2e tests for login feature"
Deps: "Upgrade dependencies to latest versions"
Build: "Configure build to support new plugins"
Пример:
feat(auth): add support for Google OAuth
Шаг 4: Дополните сообщение (опционально)
Если нужно, добавьте тело сообщения. Опишите детали:
Что именно изменено?
Зачем это сделано?
Какие дополнительные сведения нужно знать?
Пример:
fix(ui): fix button display issue
Ensure proper button rendering on low-resolution screens.
Шаг 5: Укажите BREAKING CHANGE (если нужно)
Если изменение несовместимо с предыдущими версиями, укажите это в сообщении:
Пример:
feat(api): remove support for legacy data format
BREAKING CHANGE: API no longer supports XML.
Готовые примеры для для вдохновения⭐️
-
Добавление новой функциональности:
feat(auth): add Google authentication support
-
Исправление ошибки:
fix(ui): fix button alignment issue
-
Обновление документации:
docs: update API documentation
-
Оптимизация производительности:
perf(core): reduce application load time
-
Критическое изменение:
feat(api): remove support for old endpoints BREAKING CHANGE: deprecated endpoints removed.
-
Откат изменений:
revert: revert commit c12345 Reverts changes that broke login functionality.
Надеюсь, эта шпаргалка станет удобным подспорьем в написании чётких и полезных сообщений для коммитов. Делитесь в комментариях своими интересными кейсами, как вы используете Conventional Commits, чтобы учиться друг у друга и находить новые идеи!?
Nartsiss
Breaking changes принято указывать с "!", например: