Gymterview
middle

Что такое Conventional Commits?

Conventional Commits — это спецификация для стандартизации формата коммит-сообщений, обеспечивающая единообразную историю, автоматическую генерацию changelog и определение следующей версии по типам коммитов.

Формат

Пример
<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Примеры:

Пример
feat(auth): add JWT token refresh endpoint

fix(payment): correct rounding error in tax calculation

refactor(user-service): extract validation logic to separate class

docs: update README with new build instructions

chore(deps): upgrade Spring Boot to 3.3.0

Типы (types)

Тип Назначение Влияние на версию
feat Новая функциональность MINOR (1.x.0)
fix Исправление бага PATCH (1.0.x)
docs Изменения в документации –
style Форматирование, без изменения логики –
refactor Рефакторинг (не fix и не feat) –
test Добавление/исправление тестов –
chore Сборка, CI, зависимости –
perf Улучшение производительности PATCH
ci Изменения в CI/CD конфигурации –
build Изменения в системе сборки –
revert Откат предыдущего коммита –

Breaking Changes

Несовместимые изменения обозначаются двумя способами:

Пример
# Способ 1: восклицательный знак после типа
feat(api)!: change response format to JSON:API

# Способ 2: футер BREAKING CHANGE
feat(api): change response format

BREAKING CHANGE: response format changed from custom JSON to JSON:API.
All clients must update parsers.

Breaking change увеличивает MAJOR версию (x.0.0).

Связь с Semantic Versioning

Пример
fix: ...              -> v1.0.1  (PATCH)
feat: ...             -> v1.1.0  (MINOR)
feat!: ...            -> v2.0.0  (MAJOR)
BREAKING CHANGE: ...  -> v2.0.0  (MAJOR)

Автоматизация

Пример
# Установка commitlint (проверка формата)
npm install -g @commitlint/cli @commitlint/config-conventional

# Использование с Husky (git hooks)
npx husky add .husky/commit-msg 'npx commitlint --edit $1'

# Автогенерация changelog
npx conventional-changelog -p angular -i CHANGELOG.md -s

# Автоматический релиз с semantic-release
npx semantic-release

Ключевые моменты

  • Conventional Commits — это спецификация, а не инструмент. Валидация выполняется через commitlint или git hooks
  • Формат позволяет автоматически определять тип версии (MAJOR/MINOR/PATCH) на основе коммитов
  • scope — необязательный, обычно указывает модуль или область изменений
  • Body и footer отделяются от заголовка пустой строкой

Частые ошибки

  • Писать описание с заглавной буквы — по конвенции начинается со строчной
  • Ставить точку в конце заголовка — не ставится
  • Превышать 72 символа в заголовке — затрудняет чтение в git log
  • Использовать неправильный тип: fix для рефакторинга или feat для исправления бага
  • Забывать про BREAKING CHANGE при несовместимых изменениях

Как используется в 2026

  • Conventional Commits — стандарт де-факто в open-source и многих enterprise-проектах
  • semantic-release и release-please автоматически создают релизы, теги и changelog на основе коммитов
  • AI-ассистенты в IDE автоматически предлагают коммит-сообщения в формате Conventional Commits
  • Интеграция с Jira/YouTrack: номер задачи в scope или footer автоматически связывает коммит с задачей

На собеседовании: покажите знание формата: type(scope): description. Перечислите основные типы (feat, fix, docs, refactor, chore) и их влияние на версию. Ключевая связь: Conventional Commits + Semantic Versioning = автоматические релизы. Упомяните инструменты: commitlint, semantic-release, Husky.

#git#best-practices#ci-cd