Skip to main content

Branching strategy

This guide describes the recommended branching strategy to manage code repositories.

Introduction​

A branching strategy is a way of organizing and managing the changes to a codebase using branches. It is important to have a branching strategy because it helps developers to collaborate effectively and efficiently on a project. It also helps to maintain the quality, stability, and security of the codebase.

It is recommended to manage source code repositories in Azure DevOps with the GitFlow branching model as described below. Gitflow is a branching model that was proposed by Vincent Driessen in 2010. This guide applies to new code repositories or to planned improvements to adopt git.

Several existing products in PCP still use TFVC (Team Foundation Version Control) due to historical reasons. In that case, the branching strategy is already well established, described in the respective CM Plan and possibly very similar in principle to the branching strategy described here, considering how it supports new and maintenance releases, although the tool is different.

Some teams that use Git may decide to follow a different branching strategy with a motivation and to document the tailoring in their CM Plan.

As the Author of GitFlow wrote, "If [..] you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild" then GitFlow is a good fit.

GitFlow​

GitFlow is based on the idea of having two main branches: master and develop, and several supporting branches for features, releases, and hotfixes.

GitFlow image The image above is from the Author's description of the model https://nvie.com/posts/a-successful-git-branching-model

The main branches in Gitflow are:

  • master: This branch contains the production-ready code that reflects the current state of the software. It is updated only when a new release is made from the develop branch or when a hotfix is applied. The master branch is also tagged with version numbers for each release.
  • develop: This branch is the integration branch for features. It contains the latest code that is under development and may not be stable. All feature branches are created from and merged back to the develop branch.

Note: The actual names of the branches may differ, as long as they are used in the same way. For example, master could be named "master" or "main". Develop could be named "integration" or "dev".

The supporting branches in Gitflow are:

  • feature: These branches are used to develop new features or bug fixes for the software. They are created from the develop branch and merged back to it when the feature is completed and tested. Feature branches have descriptive names that indicate their purpose.
  • release: These branches are used to prepare for a new release of the software. They are created from the develop branch and merged to the master and develop branches when the release is ready. Release branches have names that reflect the version number of the release, such as release-1.0 or release-1.1.
  • hotfix: These branches are used to fix urgent bugs or issues that are found in the production code. They are created from the master branch and merged back to it and the develop branch when the fix is done. Hotfix branches have names that start with hotfix and end with a unique identifier, such as hotfix-1.0.1 or hotfix-1.1.2.

Workflow​

The workflow of Gitflow is as follows:

  • When starting a new feature, a developer creates a feature branch from the develop branch and works on it locally. The developer can commit and push changes to the remote feature branch as often as needed.
  • When the feature is finished, the developer creates a pull request to merge the feature branch to the develop branch. The pull request is reviewed and approved by other developers or a team leader before merging.
  • When the develop branch has enough features for a release, a release branch is created from it. The release branch is used to perform final testing, bug fixing, and documentation updates for the release. No new features are added to the release branch.
  • When the release branch is ready, it is merged to the master branch and tagged with a version number. The master branch is then deployed to the production environment. The release branch is also merged back to the develop branch to incorporate any changes made during the release process.
  • If a critical bug or issue is found in the production code, a hotfix branch is created from the master branch. The hotfix branch is used to quickly fix the problem and test the solution. The hotfix branch is then merged back to the master and develop branches and deployed to the production environment.

Pros and Cons​

The advantages of Gitflow are:

  • It provides a clear and structured workflow for developing and releasing software.
  • It ensures that the master branch always contains stable and reliable code.
  • It allows parallel development of multiple features without affecting the main branches.
  • It facilitates collaboration and code review among developers.
  • It supports continuous delivery and DevOps practices.

The disadvantages of Gitflow are:

  • It requires more branches and merges than other branching models, which can be confusing and error-prone for some developers.
  • It can create merge conflicts when multiple developers work on the same feature or when the develop branch diverges from the master branch.

Tips & Tricks​

  • Configure policies on master, develop and release to manage changes as pull requests.

  • Do not allow anyone to bypass policies or approve their own pull requests.

  • Periodically review and update repo policies.

Example​

GitFlow example

Owner: Configuration Management Team