• abhishek srivastava

Branching Strategies for DevOps

Branching strategy is one of the important components of the CI/CD pipeline. It helps us to:

  • Manage the source code changes

  • Track changes in the code

  • Allows parallel development effectively








Sticking to a proper branching strategy helps us to gain fine control and streamline our development experience. Unmanaged source code repositories can lead to messy development process and increase complexity to configure devops tools.


Here, we will discuss different branching strategies that should be adopted in DevOps pipeline to achieve optimized results.


What is branching strategy?


As the name suggests, branching strategy tells us how branches in a repository are used in software development process. It’s a way to interact with version control system for writing and managing our source code.


In any project, different team members are involved to modify the same source code and there are high chances that it will introduce merge conflicts. We can avoid such conflicts in repository with defined branches when writing and merging the code to master branch for end product creation.


Why branching strategy is important?


A properly implemented branching strategy will be the key to creating an efficient DevOps process. DevOps is focused on creating a fast, streamlined, and efficient workflow without compromising the quality of the end product.


A branching strategy helps define how the delivery team functions and how each feature, improvement, or bug fix is handled. It also reduces the complexity of the delivery pipeline by allowing developers to focus on developments and deployments only on the relevant branches—without affecting the entire product.


How to select a branching strategy for Development?


The selection process for a branching strategy depends entirely on the users and the project requirements. Factors like the development method, scale, user preferences highly impact this selection. Additionally, other factors like CI/CD tools decide what branching strategies can be used in your DevOps pipeline.


Branching strategies that do not align or make it more difficult to implement Continuous Integration and Continuous Delivery in DevOps pipelines should not be used in a DevOps environment.


A good branching strategy should have the following characteristics:


  • Provides a clear path for the development process from initial changes to production

  • Allows users to create workflows that lead to structured releases

  • Enables parallel development

  • Optimizes developer workflow without adding any overhead.

  • Enables faster release cycles

  • Efficiently integrates with all DevOps practices and tools such as different version control systems


Widely used Branching strategy in DevOps


Now we have a better understanding of what a branching strategy is and what we are trying to achieve from it. Let’s look at some popular branching strategies currently used in the industry.


Git Flow


Git Flow is the most widely known branching strategy that takes a multi-branch approach to manage the source code. This approach consists of two main branches that live throughout the development lifecycle.


Primary Branches


master. The primary branch where all the production code is stored. Once the code in the “develop” branch is ready to be released, the changes are merged to the master branch and used in the deployment.

develop. This is where all the actual development happens. All the pre-production code is stored here, and the completed code of all the supporting branches is merged directly to the develop branch.


Support Branches


During the development, developers create different branches for specific use cases using the develop branch as the base. The following are some branches created like that:


feature-* feature branches are used to develop new features and branches off exclusively from the develop branch.


hotfix-* This is to deal with production issues where quick fixes are required. They can branch off from the master itself, but need to be merged to both master and develop branches.


release-* This branch is used to aggregate fixes and improvements and prepare for the production release. It will be branched from the develop branch and merged to both develop and master.


Advantages of Git Flow


  • Straightforward and separate branches for specific purposes with a proper naming convention

  • Ideal when handling multiple versions of the production code

  • Great for enterprise customers who need to adhere to release plans and workflows

  • Clearly defined branches that help define the test scope and test only the specific branches

  • Widespread support by most git tools


Disadvantages of Git Flow


  • Git history becomes unreadable

  • master/develop split can be redundant in most development scenarios

  • Can be complicated to integrate with CI/CD tools

  • Not recommended when users need to maintain a single production version

  • This strategy can overcomplicate the source control depending on the scope of the project

GitHub Flow


As the name suggests, this strategy was introduced by GitHub, aiming to provide a simple and lightweight approach to manage the development. It adheres to the following guidelines when managing the source control with a single primary branch.


  • master. The primary branch where code is branched off from and merged to. Anything in the master branch is deployable.

  • Any change (feature/bug) is made in a new branch derived from the master with a descriptive branch name describing the development.

  • Commit to the development branch locally and regularly push to the branch.

  • Create a pull request once the development is done so that the code can be reviewed.

  • Once the code is reviewed and approved, it must be tested in the branch before merging to the master branch.

  • From this point, users can immediately deploy the master branch with the new changes.


Advantages of GitHub Flow
  • Relatively simpler approach with a simple workflow

  • Clean and easily readable Git history

  • Ability to easily integrate into CI/CD pipelines

  • Ideal when you need to maintain a single production version

Disadvantages of GitHub Flow

  • An oversimplified approach that is not suitable when dealing with release-based developments

  • Not suitable when maintaining multiple versions of the code

  • Can lead to unstable production code if branches are not properly tested before merging with the master


Trunk Based Development (TBD)


The Trunk Based Development strategy involves developers integrating their changes directly into a shared trunk (master) at least once a day. This shared trunk is always in a releasable state. Developers can pull from this trunk, create a local repository, and then push the code to the shared trunk.


This regular integration enables developers to view each other’s changes quickly and immediately react if there are any conflicts.


Scaled Trunk Based Development


Smaller teams can commit directly to the shared trunk after build and functionality tests. However, for larger teams, development can be broken down into feature/bug-fix branches. Then, developers will push code to specific branches continuously, and this code can be verified via pull requests and tested before finally merging into the shared trunk. This approach enables development teams to both:


  • Scale seamlessly without overburdening the shared trunk

  • Maintain all the changes in a more organized and manageable manner

  • When it comes to deployment, TBD uses feature flags to manage the developments in the shared trunk. Using these feature flags, teams can toggle portions of code on or off for the build process and deploy only the necessary code in production environments.


Advantages of Trunk Based Development

  • True continuous integration as developers constantly keeps the trunk updated

  • Excellent choice for CI/CD pipelines with simpler workflows for automated testing

  • Shorter feedback loops for developers as code changes are quickly visible

  • Lead to faster release cycles

  • Smaller iterations allow teams to keep track of all the changes while reducing code conflicts and improving overall code quality

Disadvantages of Trunk Based Development

  • Non-experienced developers might find this approach daunting as they are directly interacting with the shared trunk (master)

  • Improperly managed feature flags can lead to issues

  • Shifting from more traditional methods such as Git Flow can be difficult


GitLab Flow


The GitLab strategy combines feature-driven development and feature branches with issue tracking. This strategy is similar to GitHub flow yet includes environmental branches such as development, pre-production, and production.


In GitLab Flow, development happens in one of these environmental branches, and verified and tested code is merged to other branches until they reach the production branch. Let’s assume that we have the three environmental branches mentioned above. In that case, the development workflow will be:


development. This is where all the development happens. Developers will create separate branches for the feature/bug-fix they are working on and merge them to this branch. Then, it will get reviewed and tested.

pre-production. Once the developed features and fixes are ready to be released, the source code up to that point will be merged to a pre-production branch. Then this code will go through additional testing and finally be merged with the production branch to be deployed.

production. Once the production-ready code is merged, this branch can be directly deployed in the production environment. This environment branch will only contain production-ready code.


Advantages of GitLab Flow

  • Provides proper isolation between environments and ensures a clean state in the branches

  • Easily integrates into CI/CD pipelines

  • Improves GitHub Flow while streamlining the process for a DevOps environment

  • Easier, cleaner to read the git history


Disadvantages of GitLab Flow

  • Can be complex to implement with the additional overhead of managing environmental branches

  • Development branches can get complicated and messy if not properly managed

How to choose your branching strategy


All the branching strategies mentioned above are already tried and tested branching strategies that can be used to manage your source code. However, each has its own strengths and weaknesses.


The traditional Git Flow will not be ideal for rapidly evolving DevOps environments.

The other strategies described here try to improve Git Flow and modernize it to fit an agile DevOps process.

So, as always, you have to select the best strategy that satisfies all your requirements and suits your organizational practices.

103 views1 comment

Recent Posts

See All