Git Branching Strategies for Salesforce Teams: A Practical Guide

Short answer: most Salesforce teams should start with a feature-branch model, where main always mirrors production and every change lives on its own short-lived branch. Add environment or release branches only when packaging, parallel release trains, or a large team force the issue. The Salesforce-specific part is not the Git graph, it is mapping each long-lived branch to a sandbox and handling metadata merge conflicts.

Branching strategy is where most Salesforce DevOps setups either click into place or collapse under their own weight. Copy a complex model you do not need and every developer pays a daily tax; pick one that fits your release rhythm and Git gets out of the way.

What is a Git branching strategy, and why is Salesforce different?

A branching strategy is the set of rules for how your team creates, merges and promotes branches. On Salesforce it carries extra weight for three reasons: your source of truth is declarative metadata (XML) as well as Apex, your environments are orgs and sandboxes rather than servers, and you cannot compile the whole project locally, so validation happens against an org. That makes two questions unavoidable that other stacks can defer: which branch represents which sandbox, and how you resolve conflicts in files like profiles and flows that many people touch. Salesforce DevOps Center, now generally available, leans on this by treating GitHub or Bitbucket as the single source of truth.

Which Git branching strategies do Salesforce teams actually use?

Four patterns cover almost every team:

• Feature branch (GitHub Flow). main is always releasable; each change branches off main and merges back through a pull request. Simplest to run, and the best default for most teams.
• Branch per environment. A long-lived branch per org (dev, uat, main), promoted by merging upstream. Intuitive and easy to visualize, but prone to drift when a hotfix skips a stage.
• Release branch. A short-lived release/x cut from main to stabilize a version while new work continues. Useful when you batch changes into scheduled releases.
• Gitflow. Feature, develop, release and hotfix branches together. Powerful for parallel versions and ISV packaging, heavy for a single-production team.

How do you map branches to Salesforce sandboxes?

Pair each long-lived branch with a sandbox that matches its job, and let refresh limits guide the shape. Salesforce refreshes Developer and Developer Pro sandboxes daily, Partial Copy every 5 days and Full every 29 days, so a Full sandbox used for final UAT cannot be your fast integration target. A common, low-friction mapping:

1. feature/* branches to Developer or Developer Pro sandboxes for building.
2. An integration branch to a Partial Copy sandbox for combined testing.
3. main validated against a Full sandbox before it reaches production.

The full mechanics are in how to map Git branches to Salesforce sandboxes.

How do you handle metadata merge conflicts?

This is where Salesforce branching actually hurts. Profiles, permission sets and flows are large XML files that many changes touch, so naive merges corrupt them. Keep branches short-lived so they diverge less, split profiles into permission sets, and use a Salesforce-aware merge driver that understands the XML instead of merging it line by line. We walk through that in how to set up a Salesforce-aware Git merge driver.

Which branching strategy should your team choose?

Match the model to your release cadence, not to an org chart:

• One production org, frequent releases: feature branch off main. Do not add more.
• Scheduled releases with a freeze: feature branches plus a release branch.
• ISV or multiple supported versions: Gitflow, or a package-per-branch model.

When two options look equally valid, pick the simpler one; you can always graduate later. Our decision rule for Git branching strategies turns this into a single question you can answer in a meeting. And because any model will eventually ship a bad change, pair it with a plan for rolling back failed Salesforce deployments.

Where does tooling fit in?

The strategy is Git; the tool automates the promotion along it. Platforms such as Copado, Gearset and AutoRABIT each assume a branching model, so choosing your model first keeps you from being boxed into someone else's. If you are moving an existing branching setup onto a new pipeline, our migration guide covers how to carry your branches across without a rewrite. For more Salesforce DevOps how-tos, browse our SF Guides.

FAQ

What is the best Git branching strategy for Salesforce?

For most teams, a feature-branch model with an always-releasable main branch. It is the simplest to run and scales until packaging or parallel releases force something more complex.

Should each Salesforce sandbox have its own branch?

Only long-lived branches should map to sandboxes. Short-lived feature branches share Developer sandboxes; reserve Partial Copy and Full sandboxes for integration and final validation.

Is Gitflow a good fit for Salesforce?

Gitflow suits ISVs and teams maintaining several versions at once. For a single production org it usually adds more branches than the release cadence needs.

How do I avoid profile merge conflicts?

Keep branches short-lived, prefer permission sets over profiles, and use a Salesforce-aware merge driver so XML merges by structure rather than by line.