Как правильно пушить коммиты?
Никаких "должен одним коммитом или не должен" не существует 

Если ты один, ты можешь вести только один мастер.

Если команда - вы договариваетесь в команде, как вам удобнее, оформляете это в правила и следуете.

Продукты бывают разные.
Довольно распространет git-flow, но его бездумное применение приводит к бардаку и оверинжинерингу.

Если есть какая-то фича, которую ты за один коммит не можешь сделать, то можешь сделать отдельный фича-бренч для этой фичи, И вести в ней разработку. При этому в случае срочной необходимости что-то исправить в мастере, у тебя мастер стабильный. Потом как фичу доделаешь - вмержишь в мастер.

Второй вариант использования фича-бренча - это pull request, если вы используете какой-нить code review, и перед пушем в мастер должны быть выполнены дополнительные действия - ручной код ревью или какие-от автоматические тесты, в общем что там в вашем CI наделаете.

Бывает, что одновременно разрабатывается несколько версий, тогда и "мастеров" может быть несколько (релизные ветки).

В простых проектах, обычно просто договариваются о name-convention для веток, с которыми потом проще генерировать различные release-notes, или в названии ветки включать номер тикета в багтрекере.
1) Когда продукт не сделан окончательно - это можно сравнить с твоими учебными проектами. Также хоть в мастер пуш. Вся "правильная" работа с git начинается, когда проект уже зарелизили. Потому что теперь продакшн нельзя ломать.
2) В остальном логика верна. Делаешь ветку для фичи и ведешь ее.

должен ли разработчик коммитить все что сделал одним коммитом? или ему нужно к примеру, models папку - закоммитить как "models / entities" и тд прочие папки с файлами?
такого я не встречал, но это обычно обговаривается или даже создается свод правил работы с git, чтобы все разработчики его придерживались.

Нужно ли делать merge разработчику после проверки высшего по рангу товарища? И куда это должно быть в dev?
ну тут также как обговорите.