N.B : Writing about things helps me understand how things work end to end because it forces you to fill the gaps you have in your mind when you only think about things – I wrote about this here
Here is one way you can setup your git branching/workflow, it is proven and tested especially for large organisations and it is currently used in the company I work in.
As shown above, there are two main branches: Master and Develop, then other branches (supporting) are derived from these two branches.
Master: This is the branch deployed to the live environment. The goal is to keep this branch stable at all times. Tags are created at each release point to enable easy rollbacks if needed.
Hotfix: The hotfix branches are created from the master branches are used to fix urgent issues that arise mostly immediately after deployment. They are merged back into the master branch before the master branch is deployed again. The hotfix is also merged into the develop branch.
Patch: The patch branch is used to fix issues found on the release branches when testing the release branch. They are created from the release branch and merged back into the release branch.
Release: Release branches are created from the develop branch. They are tested and patched (when necessary) as explained above before being merged to master. The release branch is also merged back to develop if patches were added.
Develop: This is the main development branch originally created from the master branch. Feature/Bug-fix branches are created from the develop branch and are merged backed to develop when the feature/bug-fix is complete and tested.
Feature: These are feature (or bug-fix depending on what is being worked on ) branches. They are created from the develop branch and are merged back to the develop branch when the feature is complete and tested.
This workflow as said above is tested and proven and enables the team work smoothly and efficiently. It is also worth mentioning that it might be an overkill for a small project/team.