01 logo

Branching Strategy

Code deployment branching strategy

By ConficlePublished about a year ago 4 min read

Hello all, we are back with our next article. In case you would like to refer our previous articles, you can find them here.

Introduction

Though this article is not about CI/CD, before moving on to the actual topic. Let us first understand the concepts that drives the need for branching strategy.

Also, before moving further, it is important to note that here we are talking about software development teams that follow AGILE methodology. This topic may or may not be applicable to Development teams follow other methodologies.

CI and CD

  1. Continuous Integration - In layman terms it refers to continuous automated merging of code written by different developers in the team. This is required to ensure code is always updated and working.
  2. Continuous deployment – This refers to the step where code is continuously deployed to code repository. Here deployment can involve multiple branches. This step is also automated and required mainly for unit and integration testing.

Now coming to main topic, in one of my previous organizations, our team was asked to do RND on the code check-in tools available. As a part of this task, we were also bound to think on what various branches should be created to support continuous integration and continuous development.

Branching strategy

Development process

Before designing branching strategy, it is important to understand the process and the requirements of the development team.

  1. In Agile development starts with stories. Each development story is independently deployable and testable.
  2. Each story should have unit and UI tests written.
  3. Each story should be deployed to code repository as soon as it completes. So that it is available for integration testing.
  4. Each story should be tested as soon as it completes. So that any bugs detected should be corrected as soon as possible.
  5. Each story that is tested and accepted by quality assurance team, should be available on production as soon as possible.

The above process can be broken into below entities.

Release

A release contains multiple features planned and agreed by agile team to delivered. Different software team follow different release strategy. For example, providing new release every week or every month.

Feature

Feature is an independent functionality, that needs to be delivered on production. For example, searching a restaurant, placing a food item order etc.

Story

Each feature is divided into multiple stories. Each story is an independently testable and deployable functionality. For example, getting list of restaurants, getting list of food items.

Story testing

Once story is completed by development team. It should be available for testing to QA team so that it can be tested for any bugs.

Story bug fixes

Bugs raised during story testing can be fixed early.

Regression/Integration testing

This is an integration testing performed by QA team on entire feature.

Regression bug fixes

QA teams may raise during regression/integration testing, which may be required to be fixed by development team.

Smoke testing

This is a testing performed by QA team on production ready build, just before the production deployment

Critical bug fixes

These are bug fixes which may be required to applied just before the software is ready for production deployment. For example, a crash fix raised during smoke testing.

From above requirements, let’s try to understand how many branches may be needed. And what is the purpose of each

Development

  1. This is a permanent branch, that serves the below purposes.
  2. First merging point, for all the developer code in the team.
  3. The code in this branch points to development environment.
  4. Automated unit and UI tests should be run on this branch.
  5. Provides the software build to QA team, required to test the individual story.
  6. Early bug fixes should be merged on this branch.
  7. Master/Production

This is a permanent branch, that servers the below purposes.

  1. Merging point of entire feature code.
  2. The code in this branch points to production environment.
  3. Provides the software build that will be deployed on production.
  4. Provides the software build to do smoke testing before the build is deployed on production.

Feature

This is a temporary branch created from Development branch for each story.

Every developer working on different story, should create respective feature branch.

Feature branches are merged back in development branch.

QA/Staging/Testing/Regression/Integration

This is permanent branch, serves the below purposes.

  1. This branch also contains all the developer code merged for all stories.
  2. The code in this branch points to staging or testing environment.
  3. This branch provides the build which will be used for integration or regression testing.
  4. Regression or integration build is intended for testing integration between multiple stories and multiple services. Whereas development build is intended for story level testing.
  5. Any bugs reported during integration testing, can be fixed directly on integration or regression branch.

Tag

Tag should be created for each release level build from master or production branch after smoke testing is successful.

Forward merge

Forward merge is activity in which code is moved forward as below.

  1. From feature branch to development branch.
  2. From development branch to QA/Testing/Staging/Integration/Regression branch. This activity is scheduled at regular events. For example, when a single or multiple sprints are completed.
  3. From QA/Testing/Staging/Integration/Regression branch to master/production branch. This activity is also carried out at regular intervals, once the regression or integration testing is successful.
  4. Tag creation from master/production branch, when smoke testing is successfully completed.

Backward merge

Backward merge is activity in which code is moved backward during one of the below events.

  1. Bug fixes applied on QA/Testing/Staging/Integration/Regression branch are moved back to development branch.
  2. Critical bug fixes that are applied on master/production branch are moved back to QA/Testing/Staging/Integration/Regression branch which are then moved back to development branch.

Summary

Below diagram summarizes the different branches we discussed above and different activities carried out in pictorial form.

appshow tointerviewmobiletech newsstartup

About the Creator

Conficle

A passionate iOS developer with more than decade of experience in creating enterprise applications for Apple devices. With a solid foundation in Swift, Objective-C, I thrive on transforming complex ideas into elegant, functional apps.

Reader insights

Be the first to share your insights about this piece.

How does it work?

Add your insights

Comments

There are no comments for this story

Be the first to respond and start the conversation.

Sign in to comment

    Find us on social media

    Miscellaneous links

    • Explore
    • Contact
    • Privacy Policy
    • Terms of Use
    • Support

    © 2026 Creatd, Inc. All Rights Reserved.