A good BRANCHING strategy is the one that adapts to your PROJECT and business needs. Every organization has a set of its own defined SDLC processes.
An example branching STRUCTURAL strategy that I have used in my project:

• Diagram: Branching strategy
• Clone the project available at github:
• git clone http://github.com/divyabhushan/structuralStrategy.git structuralStrategy

 Guidelines: 

• “master-prod”: Accepts merges/code/commits only from the “prod” branch
• “prod”: Perform only a merge --squash from “release” branch.
• Merge only when approved by “QA”
• Tag every merge in the format: v1.0, v1.1 … v1.*
• “release”: merge from the branches “dev”, “uat”, “QA”.
• Every release commit/project code version has to be approved by “QA”.
• Tag every merge in the format: r1.0, r1.1 … r1.*
• “dev” and “uat” NEVER merge with each other.
• “hotfix” branch commits are shared among any feature branches such as “dev” and “uat”
• “feature” branch is private to “dev” alone and is dropped after merging.
• CI/CD DevOps tools can be used to automate the above development and deployment to master_prod.
• Every project release: r1.0 .. r1.x on the ‘release’ branch can be tracked by Jenkins CI TOOL and will trigger a build, on a successful build continuous testing suite 
• cases will be triggered on the code. If the test passes the release will be delivered to ‘prod’ branch.
• Every source code delivered to ‘prod’ branch will be automatically deployed to ‘master_prod’ branch.

All the steps will be mentioned in a Jenkins file on a branch ‘name’ condition.