I'm trying to come up with a personal workflow. I've put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug. 

Is this a reasonable approach to version control?

The main idea is to keep the public repo tidy: 

* Each new release gets on its own branch until it's finally tagged in the master branch when it's finished.

* All work is done on "feature" or "hotfix" branches, never on an actual release branch, to prevent anomalies. 

* Merges to higher-level branches are always squashed (to avoid clutter). 

If it's overkill I don't mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I'm doing something flat out wrong or unnecessary.

**edit:** it says "always use squash", but I meant for small hotfixes; and use `rebase --interactive` for local feature branches before merging, [as explained in this article.][1] 

[https://i.sstatic.net/nQjZZ.png][2]

![flowchart][3] 


 [1]: http://sandofsky.com/blog/git-workflow.html
 [2]: https://i.sstatic.net/nQjZZ.png
 [3]: https://i.sstatic.net/nQjZZ.png