Комментарии 4
Ну так-то conventional commit - это инструмент автоматизации. И тут не только генерация change log, но и, к примеру, генерация номеров версий. И там привязка чёткая:fix - patch, feat - minor, breaking change - major.
Вы допускает ложный тезис (по крайней мере, я так прочитал, сорри, если ошибся): используя СС не обязательно писать внятные комментарии. Но ведь это не так, содержательные комментарии CC писать не мешает. А наоборот, приветствует. А что до scope - ну да, опционален. Но что мешает на уровне команды договориться и считать его обязательным?
Ну так-то conventional commit - это инструмент автоматизации
мне тут хороший человек подсказал про trailers - вот там все эти фикс, пукс, сренькс действительно уместны. И если ещё при работе в консоли и в GitExtensions более-менее всё читаемо, то в IDE эта колонка с коммитом почти всегда настолько упорото выглядит, что мотивирует не писать развёрнутых текстов. Тексты тащем-то для людей в первую очередь пишутся и должны объяснять что поменялось и почему. и для автогенерации тех самых release notes при генерации версий весь этот автомусор сильно не интересен и добавляет костылей для чистки
"я не пишу внятных commit messages потому, что мне мешает CC-префикс" - ну ок, не пользуйтесь CC. Только что-то мне подсказывает, что содержательность CM не зависит от того, используется этот префикс, или нет. Если разраба ленится внятно объяснить суть изменений (либо не способен) - это не проблема CM. Даже если он укажет scope.
Не то, лечим, imho...
Вообще тип коммита feat, fix и др. должен быть очевиден автору этого коммита с самого начала. Если в коммите наворочено всего и сразу, значит что-то пошло не так. Попробуй потом отдели мух от котлет при поиске багов или при revert.

Хватит использовать Conventional Commits