Branches in a Gitflow strategy

A Gitflow branching strategy commonly has the following branches.

feature branch

Feature branches are short-term branches where you develop features. The feature branch is created by branching off of the develop branch. Developers iterate, commit, and test code in the feature branch. When the feature is complete, the developer promotes the feature. There are only two paths forward from a feature branch:

sandbox branch

The sandbox branch is a non-standard, short-term branch for Gitflow. However, it is useful for CI/CD pipeline development. The sandbox branch is primarily used for the following purposes:

Sandbox branches are temporary in nature and are not meant to be long-lived. They should be deleted after the specific testing is complete.

develop branch

The develop branch is a long-lived branch where features are integrated, built, validated, and deployed to the development environment. All feature branches are merged into the develop branch. Merges into the develop branch are completed through a merge request that requires a successful build and two developer approvals. To prevent deletion, enable branch protection on the develop branch.

release branch

In Gitflow, release branches are short-term branches. These branches are special because you can deploy them to multiple environments, embracing the build-once, deploy-many methodology. Release branches can target the testing, staging, or production environments. After a development team has decided to promote features into higher environments, they create a new release branch and use increment the version number from the previous release. At gates in each environment, deployments require manual approvals to proceed. Release branches should require a merge request to be changed.

After the release branch has deployed to production, it should be merged back into the develop and main branches to make sure that any bugfixes or hotfixes are merged back into future development efforts.

main branch

The main branch is a long-lived branch that always represents the code that is running in production. Code is merged into the main branch automatically from a release branch after a successful deployment from the release pipeline. To prevent deletion, enable branch protection on the main branch.

bugfix branch

The bugfix branch is a short-term branch that is used to fix issues in release branches that haven't been released to production. A bugfix branch should only be used to promote fixes in release branches to the testing, staging, or production environments. A bugfix branch is always branched off of a release branch.

After the bugfix is tested, it can be promoted to the release branch through a merge request. Then you can push the release branch forward by following the standard release process.

hotfix branch

The hotfix branch is a short-term branch that is used to fix issues in production. It only be used to promote fixes that must be expedited to reach the production environment. A hotfix branch is always branched from main.

After the hotfix is tested, you can promote it to production through a merge request into the release branch that was created from main. For testing, you can then push the release branch forward by following the standard release process.