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

#Tools & Soft Skills

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 — это не бюрократия и не «для умных».

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

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

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