Branch Management
Branch Management is the practice of organizing and controlling Git branches that hold Salesforce metadata as a team moves work from a sandbox or scratch org toward production.
Definition
Branch Management is the practice of organizing and controlling Git branches that hold Salesforce metadata as a team moves work from a sandbox or scratch org toward production. A branch is a named line of development in a version control repository. Branch management decides how many branches exist, what each one represents, who can write to them, and how changes flow from a feature branch into an integration branch and finally into the branch that maps to production.
On the Salesforce platform this practice is built into DevOps Center, which connects a GitHub repository to a release pipeline and manages branches for you. It also underpins Salesforce DX, where the Org Development and Package Development models both store metadata in a source control repository. Strong branch management is what keeps parallel admin and developer work from colliding, gives every change a review checkpoint, and produces a clean audit trail of who changed what and when.
How branch management works across a Salesforce release pipeline
Why a branch is the unit of safe change
A branch is a movable pointer to a commit, so creating one is cheap and isolating. When an admin or developer starts a piece of work, they branch off a known-good baseline and make changes there without touching anyone else's code. The baseline branch stays stable while the feature branch absorbs the churn of half-finished work. This isolation is the whole point. Two people can edit the same Apex class or Flow on separate branches, and the conflict only has to be resolved once, at merge time, rather than constantly in a shared org. For Salesforce specifically, branches also give you a place to keep metadata that is not yet ready to deploy, such as a new validation rule that depends on a field still under review. Because the repository records every commit on every branch, you get a precise history of what changed, who changed it, and which work item it belonged to. That history is hard to reconstruct from an org alone, where the last save simply overwrites the previous one. Branch management turns that flat, last-writer-wins reality into a reviewable timeline.
DevOps Center manages branches for you
DevOps Center is the Salesforce-built tool that hides most of the Git mechanics behind a guided UI. You connect a GitHub repository, define a pipeline of stages, and map each stage to a sandbox. When a work item moves to In Progress, DevOps Center creates a feature branch for it automatically. You build in the sandbox, then click to commit the changes DevOps Center detected into that branch. Promoting the work item opens a pull request that merges the feature branch into the next stage's branch, and the merge triggers a deployment to the matching org. Behind the scenes, the state of each branch is tracked in the Branch object (sf_devops__Branch__c), a child of the Repository record in the DevOps Center data model. GitHub is the primary supported provider, with Bitbucket Cloud available in beta. The benefit is that an admin who has never run a Git command still gets feature branches, pull requests, and a documented merge history. The cost is less flexibility than raw Git for teams that want custom branch names or workflows that the tool does not model.
Mapping branches to the sandbox chain
Most Salesforce teams line their branches up with their environment chain so that a branch and an org always mean the same stage of readiness. A common shape is a feature branch per work item, an integration branch that gathers several features for combined testing in a UAT or partial sandbox, and a main branch whose contents always match production. Each merge moves change one step closer to release and one environment to the right. Keeping this one-to-one mapping matters because Salesforce deployments are stage-specific. What passes in a developer sandbox can still fail against the data and configuration in a full sandbox, so each branch needs its own deploy and test gate. The mapping also makes rollbacks legible. If a release goes wrong, you know exactly which branch represents production and can revert to its last good commit. Teams that skip the mapping, and let any branch deploy anywhere, lose the clear line between tested and untested change, which is the failure mode branch management exists to prevent.
Common branching strategies and when each fits
Three patterns dominate Salesforce work. Trunk-based development keeps one long-lived main branch and very short-lived feature branches that merge back within a day or two. It suits small teams with strong automated testing and a fast release cadence, because there is little divergence to reconcile. A GitFlow-style model adds a permanent development branch that sits between feature branches and main, plus dedicated release and hotfix branches. It scales to larger teams and slower, scheduled releases, at the cost of more branches to track and more merges to manage. An environment-based model names branches after orgs, such as a uat branch and a prod branch, and is the mental model DevOps Center leans toward. The right choice depends on team size, how much work runs in parallel, and how often you ship. A two-person team forcing GitFlow drowns in process; a twenty-person team on pure trunk-based risks constant collisions. Pick the lightest strategy that still keeps untested change away from production, and tighten it only when real pain shows up.
Protected branches and pull request review
Branch protection is the control that turns a branching strategy into a real safeguard. On GitHub you mark the integration and production-mapped branches as protected so no one can push to them directly. Every change has to arrive through a pull request, which forces a review and gives automation a place to run. A typical rule set requires at least one approving review, a passing validation deploy against the target org, and passing Apex tests before the merge button unlocks. For Salesforce this catches the problems that are expensive to find later, such as a missing dependency, a test that drops below the seventy-five percent coverage gate, or a hardcoded ID that only works in one org. Protection also keeps the audit trail honest, because every merge into production is tied to an approved pull request rather than an anonymous push. The discipline costs a little speed on each change. That trade is almost always worth it, since a single un-reviewed push to the production branch can break a live org for everyone.
Salesforce metadata and merge conflicts
Branch management on Salesforce carries a wrinkle that pure code teams do not face. A lot of Salesforce metadata lives in large XML files that do not merge cleanly. Page layouts, profiles, and some report and dashboard files are notorious, because a small change in the org can rewrite big sections of the file and two branches touching the same file collide hard. Teams reduce this pain in a few ways. They favor permission sets over profiles so that access changes land in smaller, separate files. They keep feature branches short-lived so files do not drift far apart before merging. They commit narrowly, capturing only the metadata a work item actually changed rather than a broad org snapshot. Where a file simply cannot be auto-merged, the resolution is manual and someone has to understand both versions. This is why short branches and frequent integration matter more on Salesforce than on many platforms. The longer a branch lives, the more its metadata diverges, and the more painful the eventual merge into the shared branch becomes.
Branch management in Salesforce DX
Salesforce DX is the source-driven foundation underneath all of this. Both DX development models expect a source control repository. The Org Development model retrieves and deploys metadata against sandboxes and production using change sets of source, while the Package Development model builds self-contained unlocked or second-generation packages from the metadata on a branch. In the package model, teams often build a package version from a specific branch, using naming conventions such as a feature branch prefixed with feature/ for individual changes and a packaging branch prefixed with packaging/ to test a package per release. DX pairs naturally with continuous integration, where a service watches the repository and runs a validation deploy and the test suite on every pull request before a branch is allowed to merge. If you outgrow the guided experience of DevOps Center, DX plus the Salesforce CLI gives you full control over branch names, build steps, and how package versions tie back to the branch they came from. The two are not rivals. DevOps Center is the managed front door, DX is the engine.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Branch Management.
Hands-on resources to go deeper on Branch Management.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Branch Management provide in CRM Analytics?
Q2. What is a primary benefit of using Branch Management?
Q3. Why are long-running branches in Branch Management problematic?
Discussion
Loading discussion…