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:
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
In the meantime, a teammate has merged a change to add a custom label for
In your VCS, there's a merge conflict in the PR in the
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
Example: change the same XML tag in a layout
Your PR changes the behavior of the
Phone field to
In the meantime, a teammate has merged a change that makes the
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:
<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.
Precision conflict resolution
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 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. Please see this article to see which document types are currently supported and which are still in pilot.
Standard conflict resolution
You can click
View and resolve conflicts to see the merge conflicts:
You can see the merge conflict in the layout, and click either
Accept Feature changes or
Accept Environment changes to choose whether to use your changes or your teammate's changes before clicking
Mark as resolved when you're happy with your choice.
Commit merge changes
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: