When you commit Salesforce metadata to source control, your VCS isn't aware that you're committing Salesforce metadata. All your VCS 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.

Gearset deconstructs each Salesforce object into individual metadata components and checks each metadata component for merge conflicts. Merge conflicts will only happen when multiple changes have been made to the same XML tag in the same metadata component.

If those changes are identical, Gearset will automatically resolve the merge conflict. Some changes to the same XML tag will be different, but result in the same behaviour in a Salesforce org. When this happens, Gearset will automatically resolve the merge conflict.

If your PR has merge conflicts in files that don't contain Salesforce metadata, Gearset will use the version from your PR when resolving the merge conflicts.

Gearset's component-based approach to merge conflicts means that:

  • merge conflicts happen less often.

  • when merge conflicts do happen, they indicate a genuine problem where multiple people have changed the same metadata component.

  • merge conflicts are simpler to resolve, with no risk of breaking unrelated components that are in the same file.

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's some examples that show the differences.

Example: adding different custom labels

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's no merge conflicts in the pull request.

When Gearset checks the PR for merge conflicts, it breaks the CustomLabels.labels-meta.xml file down into the individual custom labels, and compares each label to check for merge conflicts.

Gearset sees that each change adds a different custom label, so can automatically resolve the merge conflict by taking both new custom labels.

Example: removing the same field permission from a profile

Your PR removes the field permission for Account.UpsellOpportunity__c.

In the meantime, a teammate has merged a change that makes both the readable and editable permissions false on Account.UpsellOpportunity__c.

In your VCS, there's a merge conflict in the PR in the Admin profile.

There's a change to line 158 (previously <readable>true</readable>) 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 no merge conflicts in the pull request.

When Gearset checks the PR for merge conflicts, it breaks the Admin profile down into the individual permissions, and compares each permission to check for merge conflicts.

You've deleted the Account.UpsellOpportunity__c permission, while your teammate has changed the same permission, but both of these changes result in the same behaviour in the Salesforce org. Gearset compares the permission from each set of changes and sees that the permission is equivalent, so can automatically resolve the merge conflict.

Example: change the same XML tag in a layout

Your PR changes the behaviour 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 <behaviour>Readonly</behaviour>) 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 <behaviour> 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.

You can click View and resolve conflicts to see the merge conflicts.

You can see the merge conflict in the layout, and click Accept these changes to choose whether to use your changes or your teammate's changes. Once you've chosen the changes to use, click Commit merge with selected resolutions 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.

Did this answer your question?