Branching Strategies for Salesforce Teams
By the end of this lesson, you'll be able to:
- Compare environment branching and trunk-based development for Salesforce teams
- Explain why long-lived feature branches are riskier on Salesforce projects
Prerequisites: Git Basics for Salesforce Developers
Environment branching
A common pattern: main maps to production, a staging (or uat) branch maps to a staging sandbox, and short-lived feature branches are cut from — and merged back into — an integration branch. Each merge upward through the environments, usually via a pull request, triggers a deployment to the matching org.
Keep feature branches short
Salesforce metadata like Flows and Profiles is stored as XML that's genuinely hard to merge by hand — two developers each editing the same Flow on separate long-lived branches is a recipe for an ugly conflict weeks later. Favoring small, frequent merges into a shared branch (a trunk-based-development-flavored approach) sidesteps most of that pain entirely.
Starting a short-lived branch from an up-to-date main
git checkout main
git pull origin main
git checkout -b feature/small-fixBranching from an up-to-date main and keeping the change small and short-lived minimizes the odds of a painful metadata merge conflict later.
Exercise
Write the Git commands to switch to main, pull the latest changes, then create a new branch called 'feature/quick-fix' from it.
Show hint
Three commands: checkout main, pull, then checkout -b.
Branching Strategies for Salesforce Teams — Quick Check
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Most Salesforce teams map Git branches to environments and keep feature branches short-lived, merging frequently — long-lived branches drift from the org's real metadata state and produce painful, hard-to-resolve merge conflicts.