We are at Dreamforce 2026, Industry Pavilion at San Francisco
February 7, 2025
Salesforce merge conflicts happen when two developers change the same metadata and Git cannot combine the versions on its own. You resolve them by opening the conflicted file, reading the conflict markers Git adds, choosing or combining the correct lines, removing the markers, then committing and re-validating the deployment. Prevented well and resolved calmly, they are a routine part of team development, not a crisis.
Conflicts are more common on Salesforce than on a standard codebase because the platform is metadata-driven. When several people edit the same profile, flow, or Apex class at once, their changes can collide during a merge. This guide explains what causes Salesforce merge conflicts, walks through how to resolve them step by step, and shows how to prevent most of them from happening at all.
Here is the quick view before the detail.
Understanding the causes is the first step to fewer conflicts. Most Salesforce merge conflicts trace back to a handful of patterns that show up in any collaborative, version-controlled project.
Salesforce stores its settings and customizations as metadata. When two people edit the same metadata file at the same time, their changes overlap and Git flags a conflict. Workflows, Apex classes, and page layouts are all prone to these metadata conflicts.
Salesforce supports both point-and-click configuration and code. Conflicts arise when an admin and a developer solve the same problem in different ways, one declaratively and one programmatically. Those two approaches often collide during a merge or deployment.
Teams use multiple sandboxes for parallel work, but sandboxes drift apart over time as hotfixes land in one place and not another. When the environments are out of sync, source control conflicts during integration are almost guaranteed.
Weak coordination is one of the biggest causes of Salesforce Git merge conflicts. Without a clear process, two people unknowingly work on the same component, and thin documentation makes it worse. The table below shows the metadata types that conflict most and how to handle each.
When a conflict does appear, the fix is methodical, not mysterious. Git merge conflict resolution follows the same core steps everywhere, and Salesforce Git integration adds only one twist: some of the files are metadata XML rather than code. Here is how to resolve Git conflicts in Salesforce cleanly, whether the file is XML metadata or an Apex class. These steps apply to merge conflicts in Salesforce development of any size, from a two-person team to a large release train.
When you pull or merge a branch, Git tells you which files conflict. Run a status check to list them, and note whether each is metadata such as XML, an Apex class, or a Lightning component. Knowing the file type shapes how you resolve it, so start by getting the full list before touching anything.
Open a conflicted file and you will see the markers Git inserts. The block between the markers shows both versions: your changes sit under one marker, the incoming changes under another, and a divider separates them. Your job is to decide what the final, correct version should look like. In a Salesforce XML file, this often means one person added a field permission and another changed a page setting in the same block.
Decide which side to keep, or blend the two if both changes belong. This is the heart of Salesforce merge conflict resolution.
When two people simply changed the same setting to different values, talk to the other developer rather than guessing. A quick conversation prevents a wrong choice that reaches production.
Once the block reads exactly as it should, delete all three conflict markers so only clean code remains. Leaving even one marker behind breaks the file, and for XML metadata it can make the whole deployment fail. Save the file when the markers are gone and the content is correct.
A resolved file still has to work. Deploy the change to a sandbox and run a validation deployment with the relevant Apex tests before it goes anywhere near production. This confirms your metadata merge did not drop a permission or break a test, which is where rushed resolutions usually go wrong.
With the tests green, mark the conflict resolved, commit the merge, and let your pipeline promote it. Committing frequently keeps the history clean and makes the next merge smaller. If your Salesforce CI/CD pipeline runs a validation on each merge, you get an extra safety check for free, and a clean metadata deployment at this stage confirms the merge is truly done. This whole loop is smoother when it sits inside a wider Salesforce release management process that already tracks every change.
Not every conflict has to be pushed through in one sitting. If a merge gets tangled and you are unsure of the right result, it is safer to abort the merge and return the branch to its last good state than to force a resolution you do not trust. Nothing is lost when you do this, since your committed work stays intact, and you can retry the merge once you have talked to the other developer or pulled the latest changes. Treating a bad merge as something you can safely undo takes the pressure off, and it stops a rushed guess from reaching your code repository. This is another reason short-lived branches help: a small merge is quick to redo, while a giant one is not.
Resolving conflicts is a skill, but preventing them is cheaper. A few habits keep source control conflicts rare in a healthy Salesforce development workflow. Many of these are core Salesforce DevOps best practices, and they build on the version-control discipline covered in our guide to the five key principles of Salesforce DevOps.
The table below connects each habit to the conflict it heads off.
Modern DevOps platforms can spot and often resolve conflicts for you. Tools such as Gearset and Copado offer semantic conflict detection, which understands Salesforce metadata rather than treating it as plain text, so they can merge many changes without manual work. For teams new to source-driven development, that safety net is worth the investment.
These tools sit inside a wider deployment process, so the cleanest results come from pairing them with a solid pipeline. Our guide to Salesforce CI/CD best practices covers how automated validation fits alongside conflict detection. Community comparisons on Forcetalks and Git branching guides on SFDCPanther are useful when you are choosing an approach, and learning paths on SaaSguru and tutorials on Salesforce Codex cover the Git fundamentals behind them.
A merge conflict happens when two developers change the same lines in the same metadata file and Git cannot decide which version to keep. Because Salesforce work is metadata-driven, these conflicts are common when several people build in the same org at once.
Open the conflicted file, read the conflict markers Git added, and decide which changes to keep or how to combine them. Remove all the markers, save the file, then deploy to a sandbox and run a validation with tests before committing and redeploying.
For XML metadata, keep both entries when they cover different fields or permissions so you do not silently drop access. For Apex, read both versions of the method and combine the logic. Always retest after resolving, since a valid-looking file can still break behavior.
Often, yes. Tools like Gearset and Copado offer semantic conflict detection that understands metadata and can merge many changes without manual effort. They reduce the load, though a person should still review conflicts that touch shared logic or access.
Use a clear branching strategy, keep branches short-lived, merge early and often, and give each component a single owner. Keeping environments in sync and breaking large files into smaller units removes most of the overlap that causes conflicts in the first place.
Merge conflicts are a normal part of collaborative development, and they are manageable with the right approach. Understand what causes them, resolve them methodically by reading the conflict markers and retesting, and prevent most of them with small branches, frequent merges, and clear ownership. Do that, and conflicts stop slowing your releases down.
If you would like help building the source control best practices and pipelines that keep conflicts rare, Minuscule Technologies offers Salesforce DevOps services and expert Salesforce consulting built around how your team works. Contact us today to get started.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
