Software development processes can make use of different branching models. Software branches emerge from the same origin and differ in the state of development to make it possible to develop on multiple development stages in parallel.
Especially feature branches are a popular approach. Feature branching creates a separate branch which is used to develop a certain software feature. The branch is merged into the master branch or trunk after the feature is finished. The master branch and other branches remain untouched while the feature is being developed.
Another branching model is to use release branches. Release branches contain single software releases of a specific version. The idea is to have a dedicated point for a released version where bug fixes and features can be added. All changes made to the master branch that apply for the specific release as well are also made in the release branch.
However, branching models like these contradict the idea of Continuous Delivery. Feature branches, for example, postpone the integration of features into the master branch. The longer the integration of new functionality is delayed, the bigger the possibility for potential merge conflicts. Feature branches are therefore only advisable in Continuous Delivery pipelines if they are short-lived and integrated into master in a timely manner.
Release versions and working upon these releases in parallel contradicts the idea of continuously shipping versions as well. Features that are implemented are ideally shipped to production as soon as possible.
This is at least the case for enterprise projects. The continuous life cycle implies that every commit is a potential candidate for production deployment. It makes sense to integrate and apply the work on the master branch, making it possible to integrate and deploy features as early as possible, verified by automated tests. The branching model of Continuous Delivery and Continuous Deployment, respectively, therefore is quite straightforward. Changes are directly applied to the master branch, built, verified, and deployed by the build pipeline.
It's usually not required to manually tag releases. Every commit in the Continuous Delivery pipeline implicitly qualifies for being released and deployed to production, unless the automated verification identifies errors.
The following figure shows the concept of a Continuous Deployment branching model:
Individual features branches are kept short-lived and are merged back to master in a timely manner. The releases are implicitly created on successful builds. Broken builds won't result in a deployment to production.
Products, as well as libraries, however, may advisably have different branching models. With multiple supported major and minor versions, and their potential bug fixes, it makes sense to implement branches for separate release versions. The release version branches, such as v1.0.2 can then be used to continue support for bug fixes, for example, into v1.0.3, while the major development continues on a newer version, such as v2.2.0.