Newer Version Available
Resolve Conflicts Between Your Local Project and Org
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 DevSandboxThe 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 DevSandboxYour 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