Conventional Commit Linter
Проверить сообщение коммита на соответствие Conventional Commits.
Как это работает
Conventional Commits это негласный стандарт, по которому фиксится тип строчкой коммита, вроде feat или fix, а дальше в скобках необязательный scope и через двоеточие само описание. Красиво в теории, но на практике половина команды пишет по своему, а от этого потом страдает автоматическая генерация changelog. Git commit lint online проверяет сообщение коммита на соответствие формату прямо перед тем, как оно улетит в историю репозитория.
Проверка охватывает несколько частых требований сразу: правильный тип коммита из допустимого списка, ограничение длины первой строки, которое рекомендуется держать в пределах семидесяти двух символов ради читаемости в git log, отсутствие точки в конце и строчная буква в начале самого описания после двоеточия.
Удобно использовать перед коммитом, особенно если в команде принято генерировать changelog автоматически на основе истории коммитов, потому что один коммит не по формату потом ломает или искажает автоматическую сборку списка изменений для релиза.
Частые вопросы
Какие типы коммитов считаются допустимыми в Conventional Commits?
Стандартный набор включает feat для новой функциональности, fix для исправления багов, docs для документации, style для форматирования без изменения логики, refactor, perf, test, build, ci, chore и revert для отката изменений.
Обязательно ли указывать scope в скобках после типа коммита?
Нет, scope в скобках это необязательная часть формата, коммит вида fix двоеточие описание без скобок тоже полностью валиден по спецификации Conventional Commits.
Что означает восклицательный знак после типа коммита, например feat восклицательный знак двоеточие?
Восклицательный знак сигнализирует о breaking change, обратно несовместимом изменении, это важно для автоматических систем версионирования по семантическому версионированию, которые повышают major версию именно из-за такой пометки.
Почему первая строка коммита должна быть короче семидесяти двух символов?
Это ограничение исторически связано с тем, как git log и большинство терминалов отображают однострочные сообщения, более длинная строка обрезается или переносится некрасиво в стандартном выводе.