Conflict Resolution with Git Integration

Updated 1 month ago by Copado Solutions

When multiple streams of work contribute to a Git repository, merge conflicts will happen for sure, specially when 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 conflicts functionality.

Copado will always try first to perform a Git merge, and only if there are conflicts, Copado will take 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
  • 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 changed, but there is no actual unresolvable conflict. Copado will add both fields and report no issues.

An email notification will be sent whenever Copado auto-resolves conflicts.

Every time Copado auto-resolves the 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.
 
Feature branches get merged in ascending order based on the user story number*. 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 situation can be detected in advance with the User Story Overlap Awareness feature. It 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 PROD 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 both user stories' feature branches contain the same version of Class A as in the UAT environment.
  3. Create a new promotion deployment. Now 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

*As of v12., you can change the order in which user stories get merged and define your own order criteria. For more information check out the article Override User Story Promotion Merge Order.

Additional Reading


How did we do?