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.

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.

Gearset's 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 XML tag.

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.

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 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.

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?