One of the issues that commonly crops up when working in a large deployment team is how to selectively merge metadata or work around merge conflicts.

In this article we'll discuss:

Merge conflicts are situations where there are two competing changes to a single part of metadata which cannot be automatically resolved by your version control system.

The conflicts must be resolved manually before the pull request (or merge request) can be completed.

Merge conflicts typically arise when teams of developers and admins work on a common set of metadata components, such as Apex classes or custom objects.

The merge conflict is flagged when one developer attempts to merge their branch into another - usually when a feature branch is merged into master ahead of a release to integration testing or production.

Let's take an example to see how this arises in practice.

Merge conflicts can take time to resolve. As such, it's worth taking steps to avoid them where possible. Gearset can help teams avoid merge conflicts in three ways:

Let's take another example to demonstrate how this decomposition works in Gearset.

Jason has made two changes to the Opportunity object in his development environment - adding a new field, and modifying an existing one. He only wants to move the new field into production. Unbeknownst to Jason, Matt has made another change to the same object directly in production - he has also modified the existing field.

Moving just this single change with Change Sets or with the Force.com Migration Tool would be tricky, and very error-prone.

With Gearset, it is nice and easy as each of the changes are treated as separate components that Jason can deploy in isolation.

Here we can see the field in the Opportunity that he's modified to add some help text.

And here we can see the new field that he's added to the Opportunity object.
​
​

It is then very easy for Jason to select just the changes that he's ready to promote to his production environment. As he's not moving the field that both he and Matt have modified, he won't run into a conflict and can deploy his new field with confidence.

When you do run into a merge conflict, there are two main options.

To perform a manual merge, you really need to get the Apex or VisualForce from both orgs, and then reconcile the differences using something like KDiff or Eclipse. Once you have your merged file, you can then use Gearset to deploy the files from your local machine into your target org.

As demonstrated in the example above, if you're using version control to manage revisions to your code, another option is to kick off the merge / pull request process to resolve conflicts. Once the code has been merged and committed to a release branch, you can then deploy it out to your Salesforce orgs using Gearset.

In an ideal world, every merge conflict would be automatically resolved, so teams don't have to spend time manually fixing them.

Version control systems such as GitHub have been designed from the ground to facilitate this process, and have powerful algorithms for automatically handling merge conflicts. However, in some cases, this automatic resolution is just not possible.

Code has too much meaning to just automatically merge the files if there is a conflict. Successfully integrating two sets of changes relies on knowledge that only the developer has. It can be a slow process, but it's too risky to do ‘best-effort’ and end up with an Apex class that doesn’t compile!

It's worth reiterating that no tool can handle this situation - despite the claims of some other release management tools for Salesforce! This problem exists across every development platform and language, and none have managed to find a way to automatically resolve these conflicts.

There are a few good guides to handling merge conflicts: