Линтер коммитов, встроенный в git hook, отлично ловит нарушение прямо на месте — в момент конкретного коммита. Но он ничего не говорит о состоянии всей уже накопленной истории репозитория, а именно этот вопрос встаёт перед внедрением автоматического changelog.
Разница между проверкой одного коммита и проверкой истории
Git hook проверяет коммит в момент его создания и ничего не знает о тысяче коммитов, сделанных до его установки. Реальный вопрос при оценке готовности к автоматическому changelog — какой процент всей истории соответствует формату, а не проходит ли последний коммит проверку.
Практический порог для автоматического changelog
git log --pretty=%s | head -100Собрав список последних коммитов таким образом и прогнав через пакетную проверку, легко получить конкретную цифру соответствия. Для репозитория, планирующего полагаться на автоматическую генерацию changelog, разумный ориентир — выше девяноста процентов, иначе changelog систематически теряет часть значимых изменений.
На что не стоит списывать несоответствие
| Причина несоответствия | Стоит ли беспокоиться |
|---|---|
| Merge-коммиты вида “Merge branch” | Обычно нормально, не Conventional Commits по своей природе |
| Коммиты до внедрения git hook | Ожидаемо, история до правила естественно ниже стандарта |
| Свежие коммиты после внедрения hook | Стоит разобраться, почему hook не остановил |
Как получить честную цифру, а не ощущение
Проверять каждый коммит по одному через одиночный линтер, чтобы получить общую статистику, неудобно при истории в тысячи коммитов. Git Commit History Batch Linter считает процент соответствия сразу по всему списку.
Итоговый чеклист
Git hook защищает будущие коммиты, но не даёт представления о состоянии уже накопленной истории репозитория.
Порог выше девяноста процентов соответствия — разумный ориентир перед тем, как полагаться на автоматическую генерацию changelog по истории.
Merge-коммиты и история до внедрения git hook — ожидаемые исключения, которые не стоит списывать на слабую дисциплину команды.