When using pipelines, conflicts are detected by our standard merge conflict resolution which gives you the ability to resolve a conflict by choosing the version of a conflicted file from either the feature branch or the environment branch. The file is selected in its entirety.

Sometimes, due to the complex nature of content changes, the resultant merge may require a combination of changes from the feature and environment branches. With precision conflict resolution, you have the ability to choose from either side on a per-conflict basis - so the resultant file's resolution can be a mix of both feature and environment branches.

There are two main types of conflict that you will likely encounter.

Content conflicts occur when the same file at the same file path in your repository has been changed on the Feature and on the Environment, but some or all of the changes conflict, and require a decision on which content to keep and what the final file should look like after the merge.

Gearset supports resolving conflicts in most of these scenarios.

Path-related conflict are caused by files being renamed, deleted, or added in a way that git decides is a conflict. These are sometimes genuine conflicts, but they are often false positives.. This means git has decided a conflict exists, but it is really just deciding this based on the files being very similar. Gearset's support for these scenarios is currently being extended to help cover most of them. An advanced explanation of this category of conflicts can be found here.

As previously mentioned, we can't always provide precision conflict resolution. In these cases, we offer a simpler method where you choose to keep either the Feature or Environment version of the file to resolve the conflict.

File types currently supported in this mode: Salesforce metadata and general XML

For compatible metadata file types, Gearset provides a side-by-side comparison that shows only the conflicted differences between the Feature and Environment files. Any non-conflicting changes have been applied to these files, so what you see here reflects how the file will look after the conflicts have been resolved.

In this interface, you can decide which version of a conflict you want to retain during the file merge, either choosing to apply the version from your feature, or retaining the change that was made on the Environment side since you branched.

Use the "Next" and "Prev" buttons to move between conflicts within the file. When you click "Next", you'll be taken to the subsequent conflict. Keep in mind, conflicts might not align perfectly between the two panes due to differing line placements in the documents. To bring a related conflict into view, simply click the link icon next to its checkbox.

After addressing all conflicts, finalize your choices by hitting "Mark as resolved". Review the resolved files by selecting them from the left pane. Should you need to adjust any conflict selections, simply select "Edit".

After resolving all files, finalize the process by clicking the "Commit merge" button.

For the subset of non-XML types listed above, Gearset provides a single pane view that will show the merged file with conflicts highlighted. You can select to use either the feature changes of the environment changes or both.

The "Next" and "Prev" buttons can be used to navigate between the conflicts in the file. Once all conflicts have been selected, you can finalise the selection by clicking on "Mark as resolved". Resolved files can be reviewed by selecting them on the left-hand pane and viewing the resultant files. If you need to modify the conflict selection you can click "Edit".

Once all files have been resolved the complete resolution can be committed using the "Commit merge" button.

When a conflict cannot be resolved simply by selecting the Feature, the Environment, or both, we offer manual conflict resolution.

This allows direct editing of these conflict blocks.

The resulting changes will immediately be reflected in the file being resolved

We offer extended support for Apex .cls and .trigger files by running a check on their contents to ensure that it appears to be valid Apex code. This is a simple syntax check and may not catch all problems in your code, but it should catch situations where a syntax error has been introduced by manual editing or selecting both sides of a conflict.

The error message above will be displayed when you attempt to resolve a file that contains malformed Apex.