Since Version 3.0.0 a branching model based on https://nvie.com/posts/a-successful-git-branching-model/ is used.
tag tag tag
v v v
master #--------------------------------#--------------------#--- stable
\ / /
(release) \ #--#--# #--# locally prepare merge to master
\ / /
develop ----#--#------#--#--#--#----#-------#--#-------#---------- public dev branch
\ /
(feature) #--# local dev branches
The public master branch always reflects the currently released actual version, i.e. a production-ready state.
Merges to master must always cause a new release.
The public develop branch reflects the state of the latest stable development state. The code here is tested but waiting for more changes to accumulate, before a new release is triggered.
The release branch is a temporary preparation branch. It is always branched from the develop branch, when enough changes piled up. This is the last stage where version numbers are updated, final tests are made and changelog is finalised before it is merged to master.
releasebranches are named release-x.y.z. In most cases they are not pushed to GitHub.
feature branches are temporary branches for creating features, that can not be implemented directly in the develop branch. feature branches are branched/merged from/to develop.
In most cases they are not pushed to GitHub and are named depending on the feature they implement.