Никаких "должен одним коммитом или не должен" не существует
Если ты один, ты можешь вести только один мастер.
Если команда - вы договариваетесь в команде, как вам удобнее, оформляете это в правила и следуете.
Продукты бывают разные.
Довольно распространет git-flow, но его бездумное применение приводит к бардаку и оверинжинерингу.
Если есть какая-то фича, которую ты за один коммит не можешь сделать, то можешь сделать отдельный фича-бренч для этой фичи, И вести в ней разработку. При этому в случае срочной необходимости что-то исправить в мастере, у тебя мастер стабильный. Потом как фичу доделаешь - вмержишь в мастер.
Второй вариант использования фича-бренча - это pull request, если вы используете какой-нить code review, и перед пушем в мастер должны быть выполнены дополнительные действия - ручной код ревью или какие-от автоматические тесты, в общем что там в вашем CI наделаете.
Бывает, что одновременно разрабатывается несколько версий, тогда и "мастеров" может быть несколько (релизные ветки).
В простых проектах, обычно просто договариваются о name-convention для веток, с которыми потом проще генерировать различные release-notes, или в названии ветки включать номер тикета в багтрекере.
