Conflict Resolution with Git Integration

Updated 3 months ago by Copado Solutions

When multiple streams of work contribute to a Git repository, merge conflicts will happen for sure, specially given that Salesforce's metadata is mostly XML-based.

To avoid having users to resolve conflicts in Git (where they run the risk of producing an invalid XML and having to clone the repository and resolve conflicts locally), Copado has implemented an auto-resolve conflict functionality.

Copado always tries first to perform a Git merge, and only if there are conflicts, Copado takes different strategies to auto-resolve these conflicts depending on the type of file.

Consider the scenario where branch A is being merged into branch B:

  • XML-based files: Copado will do a semantic merge of the XML nodes for the following metadata types:
    • Profile
    • PermissionSet
    • WorkFlow
    • CustomObject
    • CustomLabels
    • AssignmentRules
    • Translations
    • CustomObjectTranslation
    • AutoResponseRules
    • MatchingRules
    • SharingRules
  • StaticResources:
    • Using the unzip option in the Git snapshot: Recommended for javascript and css. Copado will create a new zip file with the merged content.
    • Not using the unzip option: The typical use is for images and binary content, A will win over B.
  • All other files:
    • A will win over B.

Semantic merge is attempted in circumstances such as when there are two new fields in the same object, in different branches. Git reports a conflict because the same XML sections have changed, but there is no actual unsolvable conflict. Copado will add both fields and report no issues.

An email notification is sent whenever Copado auto-resolves conflicts.

Every time Copado auto-resolves conflicts in a Git merge, everything gets documented in your Git repository. In a Git merge, even if branch A wins over branch B, this automated version can be reverted easily. A third version of the file can be produced at any time by one of your developers/release managers in order to replace the automated one. 

Promotions with Overlapped Metadata in User Stories

It is important to understand that when a promotion branch is created, the feature branches of the promoted user stories get merged into the promotion branch, with the version of the files as in the feature branches, not the source org branch.

By default, feature branches get merged in ascending order based on the User Story Reference field, however, you can override this and define your own merge order criteria (for more information about how to do this check out the article Override User Story Promotion Merge Order). If there are overlapped metadata, e.g. two or more user stories contain the same Apex class, Copado will try first a Git merge, but if there is a Git conflict, the feature branch version of the file will win over the promotion branch. This could lead to the last user story overwriting other user stories in the same promotion.

This type of situation can be detected in advance with the User Story Overlap Awareness feature. This can also be detected when creating the promotion deployment, since Copado sends the running user an email with a detailed report of the files that have been automatically resolved.

Once the situation is detected, this is the way to proceed: you need to sync the feature branches so that they have the same version of the overlapped file.

Let’s say you are promoting from UAT into production and User Story 1 and User Story 2 contain class A:

  1. Go to User Story 1, click on Commit Files and commit class A, and the same for User Story 2.
  2. Now the feature branches in both user stories contain the same version of class A as the UAT environment.
  3. Create a new promotion deployment. Class A will contain the intended content in the promotion branch.

For more information on the CBM + CCM release process, check out the article CBM + CCM Release Process.

Additional Reading

How did we do?