Branching and Merging Strategies in SCM – Part 2
In the previous blog, we explored the fundamentals of Branching and Merging Strategies in SCM, including key patterns and release-centric models. In this part, we’ll take a closer look at how different development methodologies—like Waterfall and Agile—shape branching workflows, along with the role of DevOps, popular SCM tools, and Trunk-Based Development in modern software practices.
Branching Model
A branching model outlines the structure used for branching within a project’s Software Development Life Cycle (SDLC). It can involve a single branch or multiple branches, and the approach to branching and merging is typically shaped by the software development methodology adopted by the organisation or project.
Types of Branches
Different types of branches are used during software development, each serving a unique purpose. Below are some of the commonly used branch types:
Main Branch
This branch is typically the most reliable and contains the latest production-ready version of the code. No active development or changes are made directly in this branch.
Release Branch
The Release branch, originating from the Main branch, contains the codebase from the most recent stable release. It’s used to prepare for the next deployment, with minimal or no development done on this branch.
Develop Branch
Created from the Release branch, the Develop branch is where most of the coding happens. Developers commit changes here, and nightly builds are usually run. Code from this branch is deployed to lower environments for testing across performance, quality, and functionality.
Feature Branch
Feature branches are used to work on individual features separately. They enable teams to develop without disrupting other ongoing tasks. After a feature is finalised and verified, it is integrated into the Develop branch. If it fails to meet expectations or isn’t feasible, the branch may be deleted.
Hotfix Branch
Hotfix branches are initiated from the most recently stabilised code in the Main branch. They are used to fix critical issues in the live environment that require immediate attention and can’t be deferred until the next planned release. Once the urgent fix is applied, the changes are merged into both the Main and Develop branches to maintain alignment.
Take your expertise to the next level with our
DevOps Training
Software Development Methodologies
The structure of a branching model often varies depending on the software development methodology being followed in a project.
The Software Development Life Cycle (SDLC) is a systematic process that defines each phase involved in building a software application. Each phase includes specific activities, responsibilities, and roles. It serves as a roadmap for planning, building, testing, and delivering software applications.
Typically, the SDLC starts once the project is initiated or approved and concludes when the final software product is delivered or released into production. Each stage results in specific outputs (artifacts), which then serve as inputs for the following stages.
There are different SDLC methodologies, each with a unique approach to how tasks are executed. Common ones include:
- Waterfall Model
- V-Model
- Agile Methodology
Waterfall Model
The Waterfall model follows a linear and sequential approach, where each phase of the Software Development Life Cycle (SDLC) is completed one after the other. At any given time, the project progresses through a single SDLC phase. Once a phase is finished, reviewed, and approved, only then does the process move forward to the next phase — and returning to a previous phase is not typically allowed. This model works best for projects with clearly defined requirements, stable product scope, and technologies that are well understood from the start.
In projects using the Waterfall methodology, the branching model generally adheres to a step-by-step, sequential workflow. For instance, a new branch is usually created only after the previous one is closed, such as when a release has been successfully deployed to production.
Agile Model
The Agile model is based on an iterative and incremental approach, where the SDLC is repeated multiple times throughout the project’s life. Agile methodologies are known for being flexible and adaptive, with minimal documentation and the ability to accommodate frequent changes during product development.
In each iteration, a part of the software is improved or expanded, and the updated version is presented to the client or end user. Their feedback is then used to refine the requirements, guiding the next phase of development. This cycle continues through several iterations until the complete software product is built and aligns with all expected requirements.
Popular Agile practices include:
- TDD (Test-Driven Development)
- User Stories (descriptions of features based on what the user wants and needs)
- XP (Extreme Programming)
- Scrum (structured around time-boxed sprints)
In a project using the Agile methodology, the branching model typically follows an iterative workflow. For example, multiple branches might be created simultaneously to support different releases running in parallel.
Branching & Merging Model Timeline – Waterfall vs. Agile
Let’s look at a timeline-based model to understand how the branching and merging flows differ between Waterfall and Agile methodologies. In this illustration, the icon “C” indicates code commits, “M” signifies merged code, and “R” stands for a product or code release. As depicted, the Waterfall model follows a linear sequence where new branches are created only after the completion of the prior release, whereas the Agile model supports concurrent development through parallel releases.
Driving Success with DevOps in Your Branching Strategy
Including a DevOps branch in your SCM branching model can serve as a valuable enhancement, though it’s not a mandatory component. Having a dedicated branch for DevOps-related data can offer multiple advantages, a few of which are outlined here. This branch remains separate from the main codebase and is specifically used to store assets such as automated build and deployment scripts, testing and design documentation, release notes, and artifact or version details.
In scenarios where the project includes multiple applications requiring different repositories, automation scripts may vary by application. In such cases, a centralised DevOps repository can be established to manage and organise these scripts across all applications.
DevOps Structure
The structure of a DevOps branch or repository can vary based on the project’s needs. The diagram below illustrates a typical directory layout, showing the types of information that can be organised within such a branch or repository and how it adds value to the overall software development process.
DevOps Directory Structure – Key Components
Environment
This directory typically contains deployment and testing scripts tailored to specific environments. These scripts automate the transfer of code from development to higher environments, such as staging or production. Tasks might include database creation, editing environment-specific configurations, provisioning servers, or other administrative operations.
Testing Environments
The purpose of test environments is to support both manual and automated testing of new code changes. Different test types are conducted in distinct environments, and relevant automated test scripts can be stored in designated directories within the DevOps structure.
DEV (Development)
This environment is used primarily by developers for coding and testing. It contains essential development tools like compilers, libraries, and IDEs that aren’t typically present in production. Unit tests are run here to verify the smallest testable units of code. Unit testing scripts are stored within this section.
CIT (Component Integration Testing)
This stage checks the interaction between various software components and is conducted after unit testing but prior to complete system verification.
SIT (System Integration Testing)
SIT checks the functionality of the complete system by testing interactions between subsystems, ensuring they work together seamlessly and meet the overall business requirements.
UAT (User Acceptance Testing)
User Acceptance Testing ensures that the system meets the needs and expectations of end users. Typically approved by Subject Matter Experts or clients, it serves as the final validation before production deployment.
PROD (Production)
This is the live environment accessed by end-users. Code deployed here is considered final and ready for actual business use.
Design Docs
This folder includes various design and documentation files such as UI standards, scope documents, functional and technical specs, requirement traceability matrices, and user guides prepared during the development lifecycle.
Build
Contains scripts for automating build processes—compiling source code, packaging binaries, and producing final artifacts ready for deployment.
Release Notes
Contains release documentation that highlights updates, resolved issues, and any known problems for each software version. These notes often include user guides and training materials and are created by QA teams or technical writers.
Infrastructure Management
Infrastructure as Code (IaC) tools such as Ansible, Puppet, or Chef allow you to automate server setup and configuration. Scripts for this can be version-controlled and stored in a dedicated section of the DevOps branch for easy reuse and scalability.
Framework Management
Framework directories help developers manage reusable codebases and APIs, track different framework versions, and extend common functionality. Allocating a separate area within the DevOps branch enables teams to manage and enhance shared frameworks effectively.
Branching and Merging Approaches in Popular SCM Tools
Numerous version control tools are widely used across the industry. Below, we’ll explore some of the most commonly adopted tools along with the typical branching and merging strategies associated with each.
GitFlow Branching Strategy
Mercurial Branching Strategy
ClearCase Branching Strategy
ClearCase offers a flexible framework that allows teams to tailor branching strategies according to their specific development needs. It provides essential components to support structured and effective version control practices.
A ClearCase branching approach typically involves more than just defining branch types. It also incorporates strategic use of metadata like labels, attributes, and triggers, along with well-managed views, configuration specifications, standardised naming conventions, and a clear set of policies or workflows to guide development.
Key characteristics include:
- Each file maintains its own detailed version history.
- Each version of a file is based on an earlier one.
- Baseline branching and merging is fully supported.
- The first version on any new branch inherits the content from the point where the branch was created, while version 0 on the main branch starts as empty.
- Frequent and early merges are encouraged for smoother integration.
- Consolidated branches serve as integration points to help streamline final releases.
Team Foundation Server (TFS) Branching Strategy
Scenario 1 – Single Source Tree
The team collaborates using just the main source line without creating any branches. This approach suits small to mid-sized teams that don’t require feature or release isolation.
Scenario 2 – Release Branching
Branches are created to stabilise code for a release. Before the release, a separate branch is made, and once the release is finalised, relevant updates from that branch are merged back into the main codebase.
Scenario 3 – Maintenance Branching
A branch is created to support older versions without affecting ongoing production. This allows the team to patch specific issues or deliver fixes for certain users without merging those changes back into the main build unless necessary.
Scenario 4 – Feature Branching
Every new feature is built within a separate branch, and after development is finalised, it is integrated into the main codebase. This helps different teams work on separate features simultaneously without interference.
Scenario 5 – Team-Based Branching
Separate branches are established to allow individual sub-teams to operate autonomously. This ensures they’re not impacted by others’ changes and can pursue specific goals or timelines in parallel.
Subversion Branching Strategy
CVS/PVCS Branching Strategy
In CVS (Concurrent Versions System), branching can occur from any existing branch, with the main root branch often considered the trunk. Sub-branches can be organised in different branching structures depending on the project needs. This approach is particularly beneficial in configuration management tasks.
To maintain effective and streamlined merging, it’s important to follow clear and consistent branching policies:
- Create branching guidelines that fit the needs and organisation of your project and team.
- Start with a well-defined project structure.
- Create branches with specific, defined purposes.
- Limit the number of active branches to avoid unnecessary complexity.
- Although CVS allows nested branches, they should be used selectively and only when truly beneficial.
- Adopt a consistent and descriptive branch naming system to clearly indicate each branch’s purpose.
- Apply tags at every critical point — such as during merges and when branches are created.
- Ensure consistent tagging practices for better traceability across branches and the main trunk.
Trunk-Based Branching Model
Trunk-Based Development (TBD) is a version control strategy where all developers work directly on a central branch known as the “trunk,” instead of using multiple long-lived branches. Any release branches created from the trunk are typically short-term, while the trunk itself remains the core, long-term codebase.
This model encourages frequent contributions—often multiple commits daily—to the trunk. This practice minimises merge conflicts and reduces the chances of integration issues, aligning well with the principles of Continuous Integration (CI). As a result, the codebase remains stable and ready for release at any point, supporting Continuous Delivery (CD) goals. This makes Trunk-Based Development a key component in CI/CD pipelines.
A standard Trunk-Based Development workflow includes:
- Developers commit to the main branch (trunk) at least once per day
- Remote branches are reserved for releases only
- Developers may use local branches temporarily
- Hotfixes are applied directly to the trunk
- Critical fixes are selectively added to supported release branches as needed
According to various survey insights and visual data found online, Release and Development branch models were widely adopted between 1998 and 2005. However, their popularity declined due to the challenges of maintaining long-lived branches. Over time, shorter-lived branches became more common, and Trunk-Based Development (TBD) emerged as the most consistent and reliable approach. It pairs well with temporary release branches and offers smoother workflows.
Here are some key advantages of Trunk-Based Development over traditional branching strategies:
- It promotes streamlined communication and collaboration within teams due to its lean nature
- The product can be released at any given point
- Merge conflicts are smaller and easier to handle
- Integration issues surface early and can be addressed promptly
- Short-lived release branches are easier to manage and maintain
- It reduces the dependency on distributed teams for managing codebases
- Feature toggles and conditional routing simplify how features are developed, tested, and deployed
As projects and applications grow more complex, managing a large number of branches along with intricate branching and merging strategies can become difficult and error-prone. To address this, the future of project workflows leans toward minimising the number of branches rather than eliminating them entirely. Trunk-Based Development (TBD) is widely regarded as an effective model, as it reduces the risk of complex merges and keeps the codebase stable and ready for release at any time, supporting the goals of Continuous Delivery.
When following the TBD approach, it’s recommended to adopt peer code review tools or a pull-based workflow instead of direct push methods. This ensures better code quality and minimises the introduction of problematic code into the main branch. In addition to Continuous Integration practices like automated code analysis and unit testing, peer reviews act as a valuable “shift-left” strategy. Tools such as Gerrit can be used to automate and manage peer code reviews effectively.
Conclusion
Selecting the right Branching and Merging Strategies in SCM is essential for maintaining code quality, enhancing team collaboration, and enabling faster, more reliable releases. While approaches like GitFlow, Feature Branching, and DevOps branching each serve specific needs, Trunk-Based Development has emerged as a preferred model for modern, CI/CD-driven workflows. As project complexity grows, embracing simplified, well-governed branching models ensures agility, stability, and long-term success.
