Those who use git or other version control systems have processes that work for them. Here is how I use git branches to organize my projects.
This is the branch I use that is unstable, untested, and unreleased. Any features or code I’m working on is constantly checked into this branch. It may contain code that will break my project but this contains everything I’m working on.
Whenever I’m ready to test and I think my code is good, I’ll merge the develop branch into this testing branch. If I find any issues, I go back to the Develop Branch and work on my code until I’m ready to go back to this Testing Branch.
Release Branch (Named by version number)
Once testing is complete, I create a new branch off the testing branch and name it the version number such as 1.0, 1.0.1, 1.2, etc. The code in these branches will never change. This is the code that had been tested and verified. Any future changes, including bug fixes, will have to go into a new version and a new branch.
After a release, I update the master branch. This is the latest verified, tested, ‘good’ code. Why have a Master Branch when I can just use the latest Release Branch? It’s more for organizational purposes. The Release Branches help me to organize release history (easier to write release notes and sometimes debugging). The Master Branch tells me this is the latest code regardless of release version.
There are probably better ways to utilize branches and project management include release versions. But this is what continues to work for me as an individual developer.