In this article you will learn about common branch types of Git repositories with production codebases and how to properly manage them. It is assumed that you have basic understanding what a version control system (VCS) is and are familiar with concepts of repositories and branches. In the article we will consider Git VCS, but the following guidelines may be also applied to other VCSs.
The master branch
Every Git repository has a primary branch, it is usually called "master". While this branch can be renamed, in practice it is rarely done.
The master branch is created upon initialization of new repository. There is always only one primary branch (master) in a repository, and it remains throughout all codebase lifecycle.
The master branch contains a latest stable version of the codebase. No direct changes (commits) are made into this branch. The master branch is updated only by merging the staging branch into itself.
Since the master branch contains a latest stable version of the codebase, it is used as a source endpoint for production deployment of the codebase. Automatic continuous deployment pipeline may be configured for the master branch so new production deployment action is triggered on every merging with the staging branch.
The staging branch
The staging branch is used as a buffer between development branches and the master branch.
The staging branch is created by branching from the master branch. It is usually done once a stable version emerges in the master branch. Once created, the staging branch remains throughout entire lifecycle of the codebase and is the only branch of its type.
The staging branch contains a latest unstable version of the codebase. It is updated by merging development branches into itself. No direct changes (commits) are made into the staging branch.
If there is a staging deployment of the codebase, then the staging branch is used as a source endpoint for the deployment. Usually an automatic CI/CD pipeline is configured for the staging branch so on every merging with a development branch functional tests are run and upon passing a new staging deployment action is triggered.
Development branches
A development branch contains a development version of the codebase, i.e. a new feature is being developed on top of the stable version within the branch.
New development branch is created by branching from the master branch, practically making a copy of the stable version before development. Usually a branch is called by name of new feature to be developed. There may be zero to various development branches within a repository.
Developer(-s) of new feature are working within a development branch, thus making direct changes (commits) to the branch and deploying code of the branch on their local hosts (aka development deployment).
Development process lasts until the feature is implemented according to requirements and all functional tests (new and existing) are passed. After that, the branch is merged into the staging branch triggering further CI/CD actions.
When all automated tests are passed and the codebase with newly created feature is successfully deployed to the staging environment, the codebase version is considered as stable. Therefore, the staging branch is merged into the master branch, thus adopting the new feature. Upon that the development branch is deleted.
If during development of a feature the master branch has updated, all existing development branches must merge current master branch into themselves. If such merging causes new functional tests to break, they must be fixed by the feature developer(-s) to keep the development branch up-to-date with the stable version.
Conclusion
The VCS branch management guidelines described above may be applied differently in some repositories due to nature of their codebases. The guidelines may be simplified for small projects, and for some projects they may not be applicable in general.