A salesforce branching strategy only works if it accounts for one thing most git tutorials ignore: your org is a single shared state, not a collection of independent services. Two developers can write clean, non-overlapping code and still produce a broken deployment because they both touched the same permission set, the same page layout, or the same flow. Pick a branching model that maps to your sandbox structure and treats metadata as the shared resource it actually is, and most of these conflicts disappear before they reach production.
Why Salesforce Branching Isn't Like Web App Branching
In a typical web app, branching strategy exists to manage code. Merge conflicts show up as text diffs, and a reviewer resolves them in minutes. Salesforce adds a second layer: declarative metadata that lives in XML, gets edited by clicks as often as by code, and frequently has no meaningful diff view at all.
A profile change made in a sandbox by an admin, and a permission set change made by a developer in a different sandbox, don't conflict in git. They conflict in the org, once both get deployed and start fighting over the same field-level security setting. Standard branching advice assumes conflicts are visible at merge time. In Salesforce, plenty of them only appear after deployment, which is exactly why the strategy has to account for org state, not just repo state.
This is the part teams miss when they lift a branching model straight from a JavaScript project. The git history can be perfectly clean and the deployment can still fail, because the real conflict lives in metadata dependencies that git was never built to track.
Trunk-Based Development: The Case For It
Trunk-based development keeps one long-lived branch, short-lived feature branches that merge back within a day or two, and frequent integration. For Salesforce teams shipping weekly or biweekly, this is usually the right default, and I'll say plainly that most orgs overcomplicate this decision.
The advantage is simple: short-lived branches mean metadata drifts apart for a shorter window. A flow that gets modified in a feature branch and merged back within 48 hours is far less likely to collide with someone else's profile change than one sitting unmerged for three weeks. Fewer days of divergence means fewer surprises at merge time.
Trunk-based development also forces smaller, more frequent deployments, which happens to be the single best predictor of deployment success in Salesforce environments. Small changesets are easier to validate, easier to roll back, and easier to reason about when something breaks. Teams running trunk-based Salesforce pipelines report fewer all-day deployment fire drills, mostly because there's less to go wrong in any single push.
Git-Flow and Long-Lived Feature Branches: When They Still Make Sense
Git-flow, with its develop, release, and feature branches, still has a place, particularly for teams shipping a major release quarterly alongside smaller patches. If your org runs a genuine long-cycle release process, such as a CPQ overhaul or a multi-month Experience Cloud rebuild, a dedicated release branch gives you a stable place to stage and test without freezing every other team's work.
The risk is obvious once you've lived through it: the longer a feature branch stays open, the more metadata it accumulates that diverges from what's actually running in production. A feature branch open for six weeks isn't tracking six weeks of code changes. It's tracking six weeks of profile edits, validation rule tweaks, and flow versions made by everyone else, none of which show up until merge day.
If you're going to run git-flow, put a hard ceiling on feature branch age. Two weeks is a reasonable limit for Salesforce metadata; beyond that, the merge conflict resolution effort tends to grow faster than the value of the batched work.
Mapping Branches to Sandbox Types
A branching strategy without a matching sandbox map is just a diagram. Every branch needs a sandbox it deploys to, and every sandbox needs a clear owner so nobody's guessing which org reflects which branch.
- Feature branches deploy to developer or scratch orgs, one per active feature, torn down after merge.
- Integration/develop branch deploys to a shared developer sandbox where multiple feature branches land before release testing.
- Release branch deploys to a full or partial copy sandbox for UAT, matching production data volume closely enough that layout and automation issues surface early.
- Main/trunk maps to production, deployed only through validated packages, never by hand.
The failure mode to watch for is a sandbox that quietly stops matching its branch, usually because someone deployed a hotfix directly and forgot to backport it to the branch. That single gap is where org drift starts, and it compounds every sprint until a deployment fails for reasons nobody in the room can explain.
Where Metadata Merge Conflicts Actually Bite
Some metadata types conflict constantly; others almost never do. Knowing the difference tells you where to slow down and add review, and where you can safely move fast.
| Metadata Type | Conflict Frequency | Why |
|---|---|---|
| Profiles | Very High | Single file per profile, edited by many teams simultaneously |
| Permission Sets | Medium | Usually scoped narrower than profiles, but still shared across features |
| Flows | High | Version numbers increment on every save, easy to overwrite a colleague's change |
| Apex Classes | Low | Git handles code diffs well; conflicts are visible and resolvable pre-merge |
| Page Layouts | Medium-High | No true diff view; last save wins, silently |
Profiles deserve special mention because they're the worst offenders by a wide margin. Two developers each granting field access to a new field on the same profile, in different branches, produces a deployment that succeeds technically and overwrites one person's changes without any error at all. If your branching strategy doesn't address profile ownership directly, it hasn't actually solved the problem, it's just moved it downstream.
Building a Branching Model That Survives Contact With Production
The best branching strategy isn't the most sophisticated one on paper. It's the one your team follows consistently under deadline pressure, because that's when shortcuts get taken and metadata gets edited directly in production.
Start with trunk-based development as the default, reserve git-flow-style release branches for genuinely long release cycles, and enforce a strict sandbox-to-branch mapping so nobody's ever unsure which org reflects which code. Add automated dependency checks before merge, not just before deploy, so a conflicting profile edit gets caught by a reviewer instead of by a failed validation in front of the whole team.
This is exactly the gap DeployEzee is built to close. It resolves metadata dependencies automatically across branches and sandboxes, flags conflicts before they reach a deployment window, and turns a merge-and-pray process into a one-click deploy with a clear audit trail. The branching model gives you discipline; the tooling gives you the visibility to enforce it without adding a full-time release manager to your headcount.
Frequently Asked Questions
What is the best branching strategy for Salesforce deployments?
Trunk-based development is the best default for most Salesforce teams shipping weekly or biweekly releases, because short-lived feature branches limit the window where metadata can drift apart. Git-flow with dedicated release branches still makes sense for teams running genuine quarterly release cycles. The right choice depends on release cadence more than team size.
Why do Salesforce metadata merge conflicts happen even when code merges cleanly?
Git tracks text diffs well for Apex code but poorly for declarative metadata like profiles, permission sets, and flows, which often lack a meaningful diff view. Two people can edit the same profile in different branches and both merges succeed technically, silently overwriting each other's field-level security changes. The conflict only becomes visible after deployment, not during the merge itself.
How long should a Salesforce feature branch stay open before merging?
Two weeks is a reasonable ceiling for most Salesforce feature branches. Beyond that point, the metadata in the branch tends to diverge faster from production than the team can track, and merge conflict resolution starts costing more time than the batched feature saved. Shorter-lived branches consistently produce fewer deployment surprises.
Which Salesforce metadata types cause the most branching conflicts?
Profiles cause the most conflicts because a single file covers permissions edited by many teams at once, often without visible errors when overwritten. Flows and page layouts follow closely, since both lack reliable diff tools and use a last-save-wins model. Apex classes cause the fewest conflicts because git handles code diffs reliably before merge.
How does sandbox mapping relate to branching strategy?
Every branch in a Salesforce pipeline needs a corresponding sandbox so the team always knows which org reflects which code state. Without this mapping, hotfixes deployed directly to a sandbox quietly fall out of sync with their branch, which is one of the most common causes of org drift. Clear sandbox ownership per branch type prevents this gap from compounding across sprints.