Merge Behavior Change - KI-00017 Git Duplicates

Updated 1 week ago by Copado Solutions

Copado has introduced a behavior change in the way the branches are merged during the deployment process to mitigate the KI-00017. This known issue indicates that during a Promote and Deploy process, if the branches are merged by Git, without Copado intervention, Git might introduce duplicates in the XML files. This is a conflict-less Git merge and it would also happen when working with the CLI or outside of Copado.

Please read this information carefully, as this change is affecting how Copado handles Conflict resolution with Git integration.

How Can This Be Enabled in My Org?

This is not a backend push upgrade and needs to be activated by Copado Support. Please contact your CSM or Support Manager if you would like to enable this new merge behavior. This can also be deactivated at any time upon request.

Benefits

  • Currently, the merging process may fail silently when Git is under control. With the new strategy, Copado is skipping those silent merges where Git may introduce duplicates by actively applying a resolution strategy, so the merging process will no longer present duplicate elements within files and the deployment will not fail for this reason. 
  • You will no longer need to take manual actions to identify and solve duplicate conflicts. 

What Is Changing?

Now that you know what the benefits of this new behavior are, let's take a close look at the changes.

Git Merge

If the file has not been excluded from auto-resolve, Copado will identify if the file has been manipulated by Git and will apply a left-wins or right-wins strategy. If there is overlapped metadata, e.g. two or more user stories contain the same Apex class, Copado will apply an auto-resolve logic and not a Git merge. Therefore:

  • Copado will apply a left-wins strategy (feature branch content wins over promotion branch) for files that are part of the user stories being deployed that were merged by Git.
  • Copado will apply a right-wins strategy (promotion branch content wins over feature branch) for files that are not part of the user stories being deployed that were merged by Git.

This now becomes the default behavior with Git merges and/or if there is a Git conflict, whereas previously Copado only did this when there was a Git conflict. 

If the file type has been excluded from auto-resolve, this new behavior will not be applied and the process will continue as usual and you will need to take manual steps to resolve conflicts and identify duplicates if any or otherwise Git will merge.
Promotions With Overlapped Metadata in User Stories

If there is overlapped metadata within the promotion, this will lead to the last user story overwriting other user stories in the same promotion.  

For example, user stories A, B and C have changes in the same layout:

  • A in section “Billing Address”
  • B in section “Shipping Address”
  • C in section “Payment”

When merging the user stories in order:

  • A -> Promotion branch
  • B -> Promotion branch
  • C -> Promotion branch

Only the changes included in user story C will persist in the promotion branch since the left-wins strategy will be applied. 

So when different user stories share a common file and are sequentially merged during a promotion, Copado will bypass any Git merge and only keep the contribution/changes from the last file being merged (as in the example above).

Considerations

  • Nested components and source format are not supported, only full files such as objects and layouts.

Comparison Between the Current Behavior and the New Behavior

Old behavior

New behavior

Git merge: If there is overlapped metadata

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.

Copado will always apply an auto-resolve logic with left or right-wins strategy. 


How did we do?