Рабочий процесс / практики Git для небольшого проекта (блок-схема в png)

Я пытаюсь придумать личный рабочий процесс. Я собрал блок-схему гипотетической продолжительности жизни релиза: один разработчик подтолкнул к общедоступному репозиторию github + друг, помогающий с какой-то функцией и исправляющий ошибку.

Это разумный подход к контролю версий?

Основная идея состоит в том, чтобы поддерживать порядок в публичном репо:

• Каждый новый выпуск попадает в свою собственную ветку, пока не будет окончательно помечен в основной ветке, когда он будет завершен.

• Вся работа выполняется в ветках «feature» или «hotfix», а не в реальной ветке релиза, чтобы предотвратить аномалии.

• Слияния с ветвями более высокого уровня всегда перебазируются или сдавливаются (чтобы избежать беспорядка).

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

редактировать 2: исправил плохую идею в исходной блок-схеме и немного облегчил навигацию.

Что я вижу в сообществе git / github, так это

ветки мастер разработки

Вы и участники работаете в основном над разработкой, но у кого-то может быть идея или новая функция, поэтому вы создаете ветку тем, например git checkout -b user_comments.

Затем, когда вы продвигаетесь в разработке, вы переходите к мастеру, как только получаете git-версию, которой вы довольны, и помечаете ее в основной ветке как 1.0 или 1.1.2 и т. Д. (Ищите семантическое управление версиями).