Проверьте сообщение коммита по Conventional Commits и commitlint и узнайте, какое повышение версии оно даёт
Работает в вашем браузере. Ничего из того, что вы вводите, никуда не отправляется. Проверено 16 октября 2026 г..Conventional commit начинается с типа, необязательного scope и описания, например "fix(api): handle empty response". Вставьте сообщение, чтобы проверить его по 12 правилам config-conventional из commitlint, увидеть его части и релиз, который оно означает: feat — minor, fix — patch, несовместимое изменение — major.
Эта страница переведена машинным способом с английского оригинала. Перевод ещё не проверен человеком, поэтому ориентируйтесь на английскую версию. Читать английский оригинал
Вставьте сообщение коммита или нажмите на тип, например feat или fix, чтобы начать новое.
Прочитайте результат: каждое нарушенное правило простыми словами и части, на которые было разобрано сообщение.
Исправляйте сообщение, пока оно не пройдёт проверку; строка релиза показывает, означает ли оно версию major, minor или patch.
Для целого pull request переключитесь на Список заголовков и вставьте вывод git log --format=%s.
Conventional Commits — это небольшой формат сообщений коммитов, который понимают инструменты: инструменты релизов определяют по нему следующий номер версии, а инструменты changelog превращают его в примечания к выпуску. Многие команды требуют его с помощью commitlint в хуке commit-msg, и отклонённое сообщение коммита — частая мелкая неприятность.
Формат. Заголовок, затем необязательные тело и футеры, каждый раздел отделён пустой строкой:
| Часть | Пример | Правило |
|---|---|---|
| Тип | feat, fix, docs |
Один из 11, строчными буквами |
| Scope | (api) |
Необязательно, в скобках |
| Несовместимость | ! перед двоеточием |
Или футер BREAKING CHANGE |
| Описание | add login page |
Строчная первая буква, без точки в конце |
| Длина заголовка | Не более 100 символов | |
| Футер | Closes #123 |
После пустой строки |
Что проверяется. Двенадцать правил @commitlint/config-conventional: десять ошибок (пустой тип, регистр типа, список типов, пустое описание, регистр описания, точка в конце, длина заголовка, пробелы в заголовке, длина строк тела и футера) и два предупреждения (пустая строка перед телом и перед футером). Каждое нарушение объясняется простыми словами вместе с исправлением.
Повышение версии. Спецификация сопоставляет коммиты с семантическим версионированием (Semantic Versioning): fix означает patch-релиз, feat — minor, а любое несовместимое изменение, отмеченное ! или футером BREAKING CHANGE, — major. Другие типы, например docs или chore, сами по себе версию не меняют.
Целый pull request. Переключитесь в режим списка и вставьте вывод git log --format=%s main..HEAD, по одному заголовку в строке. Каждый заголовок проходит или не проходит проверку, и указывается итоговый релиз.
Ответы сверены с @commitlint/lint 19 и config-conventional на более чем 100 сообщениях. Всё работает в вашем браузере; ничего из того, что вы вводите, никуда не отправляется.
Сообщение коммита, первая строка которого состоит из типа, необязательного scope в скобках, двоеточия, пробела и краткого описания, например fix(api): handle empty response. Формат взят из спецификации Conventional Commits 1.0.0, и инструменты используют его, чтобы автоматически выбирать следующий номер версии и писать changelog.
Используйте feat для изменения, которое пользователи видят как новую возможность, fix для исправления ошибки и chore для обслуживания, которое не меняет ни того, ни другого, например обновления зависимостей. Релизы следуют из них: feat даёт minor-версию, fix — patch, а chore сам по себе релиза не даёт. docs, style, refactor, perf, test, build и ci — остальные стандартные типы.
Поставьте восклицательный знак перед двоеточием, как в feat(api)!: remove the v1 endpoints, или добавьте после пустой строки футер, который начинается с BREAKING CHANGE: и говорит, что ломается. Любой из вариантов делает релиз major-версией независимо от типа. Оба вместе допустимы и встречаются часто.
Обычно потому, что заголовок не соответствует в точности виду type: description, и commitlint не находит ни типа, ни описания. Частые причины — нет пробела после двоеточия, есть пробел перед ним, тип с заглавной буквы или неизвестный, либо типа нет вовсе. Вставьте сообщение сюда, чтобы увидеть, какая часть была разобрана неверно.
Не с config-conventional: его правило subject-case отклоняет описания в sentence case, start case, pascal case или upper case, поэтому Add login не проходит, а add login проходит. Текст в обратных кавычках или кавычках этим правилом игнорируется, так что имя вроде `Button` в начале допустимо. Команды, которым нужны заглавные буквы, меняют правило в собственной конфигурации.
Нет. По умолчанию commitlint пропускает merge-коммиты, реверты, созданные git, коммиты fixup! и squash!, а также заголовки, состоящие только из номера версии, например 1.2.3 или chore(release): 1.2.3. Эта страница пропускает те же сообщения и сообщает об этом, поэтому проверка здесь даёт тот же ответ, что и хук.
Ставки и правила меняются; проверьте источник, прежде чем полагаться на цифру.
Всё ещё не получается? Задайте вопрос об инструменте «Проверка Conventional Commits» и ответить может любой, кто знает. Учётная запись не нужна.