This is a common branching model used successfully by many development teams. It was surprising to find teams that were not aware of this model.
So here is it again, enjoy :)
Overview

Main Branches
master is the main branch where the source code of HEAD always reflects a production-ready state
develop is the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. It is also known as an “integration branch” – This is where any automatic nightly builds are built from

Feature Branches
Feature branches names should have a well defined structure
e.g. feature/[some-unique-id]/[short-title]
Talk with your team and come up with something that make sense to you. Feature branches are used to develop new features for the upcoming or a distant future release. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop or discarded

Release (Stabilization) Branches
Stabilization branches names also should have a well defined structure e.g. release/0.1.0
Release branches support preparation of a new production release. Another term used to describe these branches is “Code Freeze”. No additional features will be delivered to these branches. Release branches allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). All changes to the stabilization branch must be merged back to the develop branch

Bug Fix Branches
Bug fix branches are treated like features with well defined names e.g. bugfix/[some-unique-id]/
Bug fix branches are used to fix bugs in the development and release branches. The essence of a bug fix branch is that it exists as long as the bug fix is not confirmed, fix could be merged back into develop/release or discarded

Hotfix Branches
Same as the other branches, Hotfix branch names should have a well defined structure e.g. hotfix/[some-unique-id]/[short-title]
Hotfix branches are very much like stabilization branches in that they are also meant to prepare for a new production release, albeit unplanned. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version. These branches must merge back into develop & master branches
We should avoid using hotfixes unless really really necessary

Someone directed me to an interesting article about an "Enhanced git flow" which I found interesting.
The article can be found here: https://www.toptal.com/gitflow/enhanced-git-flow-explained
Comments