Conventional commits и commitlint

↑ 6.3 Качество кода и тестирование: продвинутый уровень · ← Предыдущая · → Следующая

Желательно~3 мин чтенияУровень: middle

Зачем это на собесе

Формат коммитов связывает историю, changelog и семантическое версионирование.

Формат

<type>(<scope>): <описание>
 
[тело]
 
[BREAKING CHANGE: ...]

Типы: feat, fix, docs, refactor, test, perf, build, ci, chore.

Примеры: feat(auth): добавить вход по SSO, fix(table): не терять фильтр при пагинации.

Связь с SemVer

Коммит	Версия
fix	patch (1.2.3 → 1.2.4)
feat	minor (1.2.3 → 1.3.0)
BREAKING CHANGE или !	major (1.2.3 → 2.0.0)

commitlint

// commitlint.config.js
export default { extends: ['@commitlint/config-conventional'] }

# .husky/commit-msg
npx --no -- commitlint --edit "$1"

Что это даёт

• автоматический changelog и версия (semantic-release, release-please, changesets);
• читаемая история и удобный поиск;
• триггеры в CI: feat → релиз.

Нюансы

• при squash-merge важен заголовок PR — он станет коммитом;
• scope согласуйте в команде (пакет, модуль).

Вопросы с ответами

Как коммиты связаны с версиями?

fix увеличивает patch, feat — minor, breaking change — major. Инструменты релизов вычисляют версию из истории.