Затем я пришёл к использованию в боевых проектов Conventional Commits (CC).

Это очень удобное соглашение, которое позволяет избавить ваш репозиторий от коммитов вида fix bug и, как отличный бонус, автоматическая генерация Changelog-а с правильной разметкой и релиз-менеджмент.

Но чтобы это всё работало правильно, нам необходимо либо найти разработчиков со 100% понимаем дела, либо включить линтинг коммитов.

Здесь нам на помощь приходит Commitlint, который с помощью простых pre-commit хуков позволяет валидировать содержимое сообщения коммита и либо пропускать его, либо выдавать ошибку. Он легко настраивается и позволяет очень быстро добавить в свой флоу разработки щепотку магии.

Единственная проблема, с которой я столкнулся — это валидация скоупов.

Скоуп в контексте CC — это место применения изменений, которые были сделаны в коммите. Например: feat(lang): add Kazakh language
В данном примере lang — это скоуп. Нет каких-то строгих правил по тому, что может являться скоупом, вы задаёте его в рамках своей бизнес-логики/фреймворка.
Но что, если наш разработчик напишет: feat(leng): add Kazakh language

С точки зрения commitlint — всё правильно, но с точки зрения Changelog-а и в целом управления скоупами — это что-то новое и в будущем вам будет сложнее искать связанные с одним скоупом коммиты.

Для решения этой проблемы в конфигурации commitlint придумали правило scope-enum которое позволяет перечислить список разрешённых скоупов в проекте. Его можно собрать самому, а можно воспользоваться python скриптом, который написал мой знакомый Галымжан @gazgolderkz — gist.

Скрипт нужно положить в папку с проектом и перед выполнением скрипта нужно выполнить сбор данных из git log с помощью команды — git log --pretty=format:%s | grep -E '^(\w+)\((\w+|\*)\)' > commits.log

В итоге будет создан csv файл, в котором отсортировано будут делать использованные вами скоупы. Осталось их почистить и добавить в конфигурацию commitlint.

Готово, вы — восхитительны, а ваш репозиторий чист и вкусно пахнет.