Что такое Conventional Commits

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

type(scope): short description

Пример для frontend-проекта:

feat(cart): add promo code field
fix(auth): keep user on login error
docs(readme): update local setup steps
ci(release): run commitlint in pipeline

Для интервью достаточно сказать, что это не отдельный инструмент и не замена Git. Это договоренность о формате. Потом ее могут использовать инструменты: commitlint, semantic-release, генераторы changelog и CI-пайплайны.

В первой строке обычно есть три части. type говорит, что произошло. scope уточняет область изменения и часто пишется в скобках. subject коротко описывает результат изменения.

На интервью можно сказать так:

Я смотрю на Conventional Commits как на маленький контракт между разработчиками и релизной автоматизацией. Если я пишу fix(search): keep filters after reload, команда сразу видит багфикс в поиске, а инструменты могут отнести изменение к patch-релизу.

Scope не обязан быть сложным. Во frontend это может быть компонент, фича, пакет, слой приложения или часть инфраструктуры: auth, checkout, ui-kit, storybook, release. Плохой scope вроде misc почти не помогает. Он только создает иллюзию порядка.

Тип должен описывать смысл изменения, а не настроение автора. Если вы исправили баг, пишите fix, даже если пришлось сильно переписать код. Если добавили новую возможность для пользователя или потребителя пакета, пишите feat. Если поменяли только тесты, документацию, CI или сборку, выбирайте тип, который команда использует для таких задач.

Плохой пример:

update checkout

Здесь непонятно, это новая возможность, багфикс, рефакторинг или изменение сборки. Без нормального типа changelog может стать бесполезным. На ревью тоже сложнее понять риск изменения. Безопаснее написать, например, fix(checkout): keep payment error visible или feat(checkout): add saved card option, чтобы команда сразу видела влияние на UI.

Conventional Commits часто используют вместе с Semantic Versioning. Типичная логика такая: fix дает patch, feat дает minor, а breaking change дает major. Но важно сказать аккуратно. Точное поведение зависит от инструмента и конфигурации проекта.

Breaking change можно пометить так:

feat(api)!: remove legacy profile fields

BREAKING CHANGE: profile response no longer includes firstName and lastName.
Use fullName instead.

Для frontend-разработчика это важно не только в библиотеках. Если вы меняете контракт API, props публичного компонента, событие аналитики или формат конфигурации, потребители могут сломаться. Поэтому breaking change нужно явно показать в истории и release notes.

На практике Conventional Commits особенно полезны там, где много людей, пакетов и релизов. В монорепозитории scope помогает понять, какой пакет изменился. В UI-kit он помогает пользователям библиотеки увидеть, что поменялось в Button, Modal или Theme. В продуктовой команде типы помогают быстро отделить багфиксы от новых возможностей.

Но формат не заменяет качество самого коммита. Если один коммит одновременно меняет API, верстку, тесты, зависимости и конфигурацию CI, правильная первая строка не спасет ревью. Лучше разделить изменения или написать body, где объясняется причина и риск.

Ответ будет сильнее, если вы покажете, как это работает в команде. Обычно правила описывают в README или contribution guide, добавляют commitlint, а проверку запускают через Git-хук или CI. Тогда формат не зависит от того, помнит ли каждый разработчик все детали.

При этом не стоит звучать слишком жестко. Для черновых коммитов на личной ветке команда может разрешать свободный формат. При merge можно использовать squash с нормальным сообщением. Важен результат: основная история, по которой выпускаются релизы, должна быть понятной и пригодной для автоматической обработки.