Все здравствуйте! У меня возникла пара вопросов, которые я уже некоторое время не могу для себя разрешить.

Вопрос 1. Каких соглашений следует придерживаться при написании коммитов до реализации некоторого труднозатратного функционала (feature)? Под труднозатратным я подразумеваю такое изменение, которое, для удобства будущего чтения
истории коммитов, необходимо разбить на несколько изменений поменьше (например, такое может возникнуть при
реализации функционала для нескольких операционных систем: первый коммит в feature-ветке относился бы к OS-1,
второй -- к OS-2 и т.д.). В общем случае рекомендуют придерживаться Conventional Commits, но тогда minor-версия
будет возрастать слишком быстро (потому как каждое изменение в рамках feature-ветки придётся помечать как feat).
На форумах предлагали следующий вариант: объединить все коммиты в ветке в один (squash), который уже пометить как
Conventional Commit. Однако в этом случае теряется история изменений... Может быть есть какой-нибудь промежуточный
вариант, допускающий автоматизацию (скажем, генерацию CHANGELOG.md), являющийся общепринятым? Хочется всё сделать правильно.

Вопрос 2. При тестировании коммита на соответствие Conventional Commits рекомендуют использовать husky и
commitlint (git-hook). Однако всё это добро необходимо всякий раз складывать в репозиторий (загружаются
node_modules весом ~100 MiB), что меня не слишком устраивает: для такой относительно небольшой задачи требуется
столько всего устанавливать! Нет ли варианта проще, что-то вроде небольшой утилиты для этого? Да и вообще, есть ли какой-то список средств для автоматизации подобных задач (аналоги commitlint, conventional-changelog, standard-version и проч.) не из npm? | @rf@mastodon.ml