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.

File content conflicts are 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 merging.

Gearset supports resolving conflicts in most of these scenarios.

File path related conflicts are caused by files being renamed, deleted, or added in a way that git decides is a conflict. These are sometimes genuine conflicts, but often these are 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 these scenarios. An advanced explanation of this category of conflicts can be found here.

As was previously mentioned, under certain circumstances we are not able to offer precision conflict resolution and in these cases we offer a simpler form of conflict resolution where you can select whether to keep the Feature version or the Environment version of the file as a way 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 that is on your feature, or retaining the change that was made since you branched on the Environment side.

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 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 Feature, 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 attempting to resolve a file that contains malformed Apex.