Олег Смоленышев

Работаете в ветке dev, периодически вливая ее в master. Для крупных задач (не входящих в один коммит) делаете отдельные ветви из dev.

Вливая dev в master, делаете это с ключом --squash как то так:

git checkout master
git merge --squash dev

Тут теоретически могут быть конфликты, если вы делали коммиты в masterпараллельно с dev, которые вам надо разрешить, а после уже добавляете и делаете один большой коммит:

git add -A
git commit -m "Merged dev: %кратко (или нет) основные изменения%"
git push

А чтобы не мозолили глаз висящие коммиты с логической незавершенностью, их можно сливать их перед merge с помощью интерактивного rebase:

git checkout dev
git rebase -i master

Откроется редактор, в котором будет список коммитов ветки dev. Здесь можете слепить ненавистные коммиты с помощью команды squash (и тогда вам предложат отредактировать сообщение) или fixup (тут не предложат) и потом сделать git push --force (для одного не критично, в толпе лучше использовать --force-with-lease.

Или есть еще вариант - лепить к предыдущему коммиту сразу с помощью git commit --amend

Ну и после merge уже можете на master лейбл версии повесить.

Есть очень простое правило - правильно так, как проще.

Можете вовсе использовать master для синхронизации всех файлов, ничего страшного если идет активная стадия разработки, Вы единственный разработчик, а релиз еще очень нескоро. И если умеете не перескакивать от одной недоделанной задачи к другой.

Как только понадобится делать релизы, там уже можно заморочиться с master, staging, feature-бранчами и тп, но только по мере необходимости.

PS. Раз уж мы действуем по принципу KISS, вместо утилиты командной строки лучше использовать удобный GUI, например на Mac это Source Tree (по-моему самая классная программа на моем ноуте).
Это также поможет работать с гитом правильнее - вручную просматривать и стейджить каждый измененный файл, а не через git add -A.