Resolve Conflicts Between Your Local Project and Org

As a best practice, if conflicts exist for components in your local project or in the org, resolve them before moving forward. You can resolve the conflict manually, or overwrite one version of a component with another. Only overwrite changes if you're certain that the new version is the one you want to use.

Say you run project deploy preview and see conflicting changes between your local project and in the org. For example, this command output shows that WidgetClass has conflicting changes but GizmoClass is ready to be deployed.

1sf project deploy preview --target-org DevSandbox
2
3Conflicts [1]. Run the command with the --ignore-conflicts flag to override.
4 Type      Fullname    Path                                                    
5 ───────── ─────────── ─────────────────────────────────────────────────────── 
6 ApexClass WidgetClass force-app/main/default/classes/WidgetClass.cls-meta.xml 
7
8No files will be deleted.
9
10Will Deploy [1] files.
11 Type      Fullname   Path                                                   
12 ───────── ────────── ────────────────────────────────────────────────────── 
13 ApexClass GizmoClass force-app/main/default/classes/GizmoClass.cls-meta.xml 
14
15No files were ignored. Update your .forceignore file if you want to ignore certain files.

If you try to actually deploy the source, Salesforce CLI reports the conflict again and stops the operation from completing. You see similar conflict messages when you run project retrieve preview. To successfully deploy or retrieve, first resolve the conflicts, and then overwrite either your local project or the org with the resolved file. Let’s see how this works.

Overwrite Conflicting Changes

If you decide that the local version is correct, overwrite the conflicting change in the org by including the --ignore-conflicts flag when you deploy. In our example, because only WidgetClass has conflicting changes, let’s first deploy just that component to get rid of the conflicts and then deploy the non-conflicting source later.

1sf project deploy start --metadata ApexClass:WidgetClass --ignore-conflicts --target-org DevSandbox

The DevSandbox org now has the same version of WidgetClass that was in your local project. When you run project deploy preview again you see no conflicting changes messages.

If, however, you decide that the version of WidgetClass in the org is the correct one, overwrite your local copy by retrieving the DevSandbox org version while ignoring conflicts.

1sf project retrieve start --metadata ApexClass:WidgetClass --ignore-conflicts --target-org DevSandbox

Your local project now has the same version of WidgetClass that was in your org.

Well done, you resolved the conflict! Now run project deploy start without any special flags to finish deploying GizmoClass and any other new local source.

1sf project deploy start --target-org DevSandbox
2Deploying v59.0 metadata to test-ikspctiorkzs@example.com using the v59.0 SOAP API.
3Deploy ID: 0Af8D00000pNtEUSA0
4Status: Succeeded | ████████████████████████████████████████ | 1/1 Components (Errors:0) | 0/0 Tests (Errors:0)
5
6Deployed Source
7=====================================================================================
8| State   Name       Type      Path                                                   
9| ─────── ────────── ───────── ────────────────────────────────────────────────────── 
10| Created GizmoClass ApexClass force-app/main/default/classes/GizmoClass.cls          
11| Created GizmoClass ApexClass force-app/main/default/classes/GizmoClass.cls-meta.xml

Salesforce DX Developer Guide

Resolve Conflicts Between Your Local Project and Org

Overwrite Conflicting Changes

See Also