Salesforce DX Developer Guide

How Salesforce Developer Experience (DX) Tooling Changes the Way You Work
Provide Developers Access to Salesforce DX Tools
Project Setup
Authorization
Metadata Coverage
Scratch Orgs
Sandboxes
Track Changes Between Your Project and Org
Manage Source Tracking for Your org
Preview Changes Identified by Source Tracking
Deploy and Retrieve Changes Identified by Source Tracking
Resolve Conflicts Between Your Local Project and Org
Best Practices
Performance Considerations of Source Tracking
Work with Data
Salesforce DX MCP Server and Tools
Development
Build and Release Your App
Unlocked Packages
Continuous Integration
Troubleshoot Salesforce DX
Limitations for Salesforce DX
PDF

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.

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.

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.

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.