Git Branching Strategy
This workflow is based on the use of some main branches. These branches are nothing special but have a certain significance attributed to them. In the Driessen model, there are two permanent branches.
- master branch – The branch from which software is released to production. Only a production-ready code can be committed to this branch. All commits are tagged since they represent releases.
Once a new commit is pushed to master it should be picked up by CD workflow to distribute the new release.
- dev branch – The main branch that developers work on.
Once a new commit is pushed to dev it should be picked up by CD workflow to deploy latest dev versions for testing.
For the ongoing development, we will have 3 types of branches.
- Feature - used to develop new features.
- Fixes - functionality fixes.
- Chores - Refactor / Fixes / Improvments not visible to the user.
Such branches will be eventually merged back into the development branch. Each branch is as small as possible. Branch should be prefixed based on the type. Use the following prefixes: feat/, fix/ chore/. For example: feat/text-char-message-edit or chore/unused-code-clean-up
Once a set of features & their associated bug fixes have been implemented and merged into the develop branch a release branch is created. The branch is assigned a name composed of the staging prefix, followed by semver. For example staging/1.2.0
The staging branch is then subjected to integration and regression testing. Any bugs identified during this phase is fixed and committed directly to the release branch. Once the release branch has been confirmed to be free of bugs, it is merged into the master branch and released into production. These fixes are also merged back into dev and other staging branches if any.
Once the staging branch is proved to be stable it should be merged into the master branch and tagged with semver tag.
Hotfixes are production issues that need an immediate fix before a planned release. The development team creates a hotfix branch from master and applies the appropriate fixes. These fixes are also merged back into dev and other staging branches if any.
See the branching graph below:
A specification for adding human and machine-readable meaning to commit messages can be found here.
This workflow is optimized for frequent releases in a continuous delivery model. There is only one permanent branch called master. To work on a new task a developer creates a feat/fix/chore branch from master and commits their work to this feature branch.
The feature branch is pushed to the remote and is kept up to date regularly. When the feature development is complete the developer issues a pull request to the master branch.
If the pull request is accepted then the feature is ready to be deployed from the feature branch. If the feature branch is deployed and there are no issues then the chances are merged to master.
However, if there are issues then the master is immediately redeployed since it is is always in a proven working state. This workflow is a variation of the Branch-Per-Feature deployment strategy.
Once a set of features & their associated bug fixes have been implemented and merged into the master branch a GitHub release is created and the branch is tagged with semver.
See the branching graph below:
