Как правильно писать Conventional Commits и зачем они нужны

25.12.2025

Conventional Commits — это простой и понятный формат сообщений коммитов в Git.
Он помогает всем участникам проекта быстро понимать, что именно было сделано и зачем.

Зачем вообще нужны правила для коммитов

Сообщение коммита — это не формальность. Это короткое описание изменения в коде.

Хорошие коммиты помогают:

понимать историю проекта
быстрее находить нужные изменения
упрощать code review
автоматически собирать changelog
корректно повышать версию проекта

Плохие коммиты выглядят так:

fix
update
changes
temp

Через месяц никто (включая автора) не вспомнит, что там происходило.

Что такое Conventional Commits простыми словами

Conventional Commits — это договорённость писать коммиты по одному шаблону:

type(scope): short description

Пример:

fix(login): validate password length

Даже без просмотра кода понятно:

это фикс
он относится к логину
речь про валидацию пароля

Базовая структура коммита

type(scope): description

1. `type` — тип изменения

Тип показывает что за изменение вы сделали.

Самые распространённые:

Type	Когда использовать
`feat`	Добавили новую функциональность
`fix`	Исправили баг
`chore`	Технические правки, конфиги, сборка
`refactor`	Переписали код без изменения поведения
`style`	Форматирование, отступы, eslint
`docs`	Документация
`test`	Тесты
`perf`	Улучшение производительности

Примеры:

feat: add export button
fix: prevent crash on load
chore: update dependencies

2. `scope` — область изменения (необязательно, но полезно)

Scope показывает, где именно произошло изменение:

компонент
страница
модуль
функциональный блок

Примеры:

feat(profile): add avatar upload
fix(api): handle 401 error
refactor(player): simplify init logic

Если scope не нужен, его можно не указывать:

fix: correct typo in text

3. `description` — коротко и по делу

Описание должно быть:

на английском
в настоящем времени
без точки в конце
с маленькой буквы
отвечать на вопрос: что сделано?

Хорошо:

fix(login): validate empty password

Плохо:

fix(login): fixed bug
fix(login): I fixed validation
fix(login): very important fix

Примеры хороших Conventional Commit’ов

Новая функциональность

feat(camera): add manual RTSP input

Исправление бага

fix(form): normalize phone number input

Технические изменения

chore(build): update vite to v5

Рефакторинг

refactor(auth): simplify authorization flow

Документация

docs(readme): add project setup section

Частая ошибка

❌ Один коммит — всё подряд:

feat: add form, fix bug, update styles

✅ Правильно — разделять:

feat(form): add registration form
fix(form): fix submit validation
style(form): align inputs spacing

Маленькие коммиты — это нормально и правильно.

Breaking changes (когда ломаешь совместимость)

Если изменение ломает старое поведение, это обязательно нужно указать.

Через `!`

feat(api)!: change auth response format

Или через описание ниже

feat(api): change auth response format

BREAKING CHANGE: token field renamed to accessToken

Это особенно важно для API и библиотек.

Почему коммиты принято писать на английском

английский — стандарт для международных команд
легче читать сторонним разработчикам
инструменты (changelog, release notes) ожидают английский
сообщения выглядят одинаково во всех проектах

Даже если команда русскоязычная — коммиты почти всегда на английском.

Краткая шпаргалка

feat(scope): add new feature
fix(scope): fix bug
chore(scope): technical changes
refactor(scope): code cleanup without behavior change
docs(scope): documentation
style(scope): formatting only
test(scope): add or update tests

Итог

Conventional Commits — это не бюрократия и не «для умных».

Это простой и рабочий способ:

писать понятные коммиты
поддерживать порядок в проекте
экономить время себе и другим

Если начать писать так сейчас, через пару недель это станет автоматическим навыком.