When you commit Salesforce metadata to source control, your VCS isn't aware that you're committing Salesforce metadata. All it knows is that you've committed some text files. When multiple changes are made to the same lines in these text files, you're left with merge conflicts in your pull requests that you need to resolve.

Gearset Pipelines knows that your VCS contains Salesforce metadata, and uses this deep understanding of metadata when checking your pull requests for merge conflicts.

Merge conflicts will only happen when multiple changes have been made to the same XML tag in the same file.

We have now added the ability to rerun merge conflict checks for promotion branches.

Note: If you change the user owning this pipeline, it will cause the Merge Conflict check to remain pending.

If those changes are identical, Gearset will automatically resolve the merge conflict.

When some of the changes within the same XML tag are conflicting, but result in the same behaviour in a Salesforce org, Gearset will automatically resolve that merge conflict.

Gearset's approach to merge conflicts means that:

This approach means that you'll sometimes see merge conflicts in your VCS, but won't see merge conflicts in Gearset (or vice-versa). Here are some examples that show the differences.

Your PR adds a custom label for emailSend:

In the meantime, a teammate has merged a change to add a custom label for downloadPdf:

In your VCS, there's a merge conflict in the PR in the CustomLabels.labels-meta.xml file.

All custom labels are stored in a single file, and a change has been made to line 2 in both your PR and your teammate's PR, by adding new custom labels. Your VCS doesn't know which change to use, so you have to resolve the merge conflict to tell it which change you want:

In Gearset, there are no merge conflicts in the pull request:

When Gearset checks the PR for merge conflicts, it recognizes that each change adds a new custom label, so it can automatically resolve the merge conflict by taking both new custom labels in the CustomLabels.labels-meta.xml file.

Your PR changes the behavior of the Phone field to Edit:

In the meantime, a teammate has merged a change that makes the Phone field Required.

In your VCS, there's a merge conflict in the PR in the layout:

There's a change to line 21 (previously <behavior>Readonly</behavior>) in both sets of changes. Your VCS doesn't know which change to use, so you have to resolve the merge conflict to tell it which change you want.

In Gearset, there's also a merge conflict in the PR:

The <behavior> tag for the Phone field was changed in both sets of changes. These changes weren't identical, so Gearset can't automatically resolve the merge conflict.

When conflicts are detected, our new precision conflict resolution feature gives you the ability to resolve a conflict by choosing from either side on a per conflict basis. This means that the resolved file be a mix of both feature and environment branches.
​
Not all file types or all conflict combinations are currently supported by our precision conflict resolution feature and there may still be some situations where we will show the standard resolution approach instead.
​

For cases where the precision conflict resolution front end cannot be shown, you will see the standard conflict resolution instead.

This view will show you all the differences between the two files and you can either choose to take the entire content of the Feature branch file, or keep the contents as it is on the Environment branch.

You can see the conflicting differences in the layout, and click either Accept Feature changes or Accept Environment changes to choose whether to use your changes or keep the current state of the Environment before clicking Mark as resolved when you're happy with your choice.

Once you've chosen the changes to use, click Commit merge to resolve the merge conflicts in the PR:

This merges your environment branch into your PR with your chosen changes, leaving no merge conflicts in your VCS or in Gearset: