Conflict Resolution with Git Integration

Updated 4 months ago by Iván Minaya

When multiple streams of work contribute to a Git repository, merge conflicts will happen for sure, especially when the Metadata of Salesforce is mostly XML-based.
To avoid having users resolving conflicts in Git (where they take 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. Depending on the type of file, Copado will take different strategies to auto-resolve the conflicts.

Copado will always try to do a "git merge" first  and only if there are conflicts, Copado will auto-resolve them as follows: 

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

  • XML based: 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 on the Git Snapshot: recommended for javascript and css, Copado will create a new Zip file with the merged content.
    • Not using the Unzip option: typical use is for images and binary content, A will win over B.
  • All the other files:
    • A will win over B.

Semantic merge is attempted in circumstances such as when there are two new fields on the same object, on different branches. Git reports a conflict because of 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 that Copado auto-resolves the conflicts in a Git merge, everything gets documented on your Git repository. In a Git merge, even if branch A wins over branch B, this automated version can be reverted easily.  A 3rd version of the file can be produced at any time by one of your Developers/Release Managers, in order to replace the automated one. 

It is important to understand that when creating a Promotion branch, 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.
The feature branches get merged in ascending order based on the User Story number. If there are overlapped metadata, e.g. 2 or more user stories contains 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 overlap awareness feature. It can also be detected when creating the promotion deployment, Copado sends an email with a detailed report of the files that were automatically resolved to the running user. 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 contains class A. Go to User Story 1, press the “Commit Files” button and commit Class A, and the same for User Story 2. Now both User Stories feature branch contains the same version of Class A as in UAT environment. Create a new Promotion deployment, now Class A will contain the intended content on the promotion branch.

Click here for more information on the CBM + CCM release process.


Here is a quick tip on how to undo the changes in Git.

git reset HEAD~n
          git push -f origin branch

Replace "n" with the number of commits to undo. Replace "origin" with the right remote name, and replace "branch" with the right branch name.

If git command line is not an alternative, you could achieve the same using a GUI such us SourceTree 

Connect your git repository, please follow SourceTree instructions for that.

The following screenshot shows the master and dev branch. Let's assume that the latest commit on the master branch was committed by mistake and you need to revert it.

By doing right click on the "unwanted commit", select "reverse commit"

This will create a new commit which is the new status.
Now you just need to push the new commit. Use the Push icon on the toolbar and confirm the action.

Finally your repository will look similar to this.

How did we do?