Salesforce DX Developer Guide

How Salesforce Developer Experience Changes the Way You Work
Enable Dev Hub Features in Your Org
Project Setup
Authorization
Metadata Coverage
Scratch Orgs
Sandboxes
Track Changes Between Your Project and Org
See Changes Identified by Source Tracking
Pulling and Pushing Changes Identified by Source Tracking
Resolve Conflicts Between Your Local Project and Org
Get Change Information by Querying the SourceMember Object
Best Practices
Differences and Considerations
Development
Build and Release Your App
First-Generation Managed Packages
Second-Generation Managed Packages
Unlocked Packages
Continuous Integration
Troubleshoot Salesforce DX
Limitations for Salesforce DX
PDF

Newer Version Available

This content describes an older version of this product. View Latest

See Changes Identified by Source Tracking

Source tracking lists changes by project. To see changes between your local project and dev org, navigate to the project directory for which you want to see changes.
  1. In a terminal or command window, navigate to the project directory. In this example, the directory is named MyProject.
  2. Run the force:source:status command. Include the -u parameter to specify the username of the scratch org or sandbox that you want to compare with your local project. In this example, the username is DevSandbox.

The CLI displays the differences between the local project and the org. In this example, the local project adds an Apex class named WidgetClass. The org includes changes to a custom object named Widget__c, that haven’t been pulled to the local project, but they conflict with Widget__c in the local project. In this example, someone working in the org deletes a listview called All on Widget__c and adds a permission set named WidgetPermissions. Pushing source to the org adds the WidgetClass ApexClass. Pulling source from the org changes Widget__c, deletes the All listview on Widget__c, and creates a permission set named WidgetPermissions in the local project.

Source tracking returns a table of change information with four columns: STATE, FULL NAME, TYPE, and PROJECT PATH. Each row represents one change.

STATE details information about the change. It tells you where and what the change is, and whether or not there is a conflict. Here’s what the different values of STATE mean.

  • Local — The change is present in your local project and awaits a push to your org.
  • Remote — The change is present in your org and awaits a pull to your local project.
  • Add — A component is created.
  • Changed — A component is edited. For example, a custom object is changed when fields are added or removed.
  • Deleted — A component is removed.
  • (Conflict) — Normally, Salesforce automatically creates, deletes, or updates components when you push or pull source. In this case, Salesforce encountered a change that it couldn’t automatically resolve. Prior to pushing or pulling changes, resolve conflicts.

FULL NAME is the API name of the component.

TYPE is the component’s metadata type. It describes what the component is, such as an Apex class or a custom object.

PROJECT PATH is the location of the component in your local project. If it’s blank, the component isn’t present in your local project. When blank, it usually means that a component is present in the org but not in your local project.

If the source in your local project and the org match, then the force:source:status command returns a statement saying No results found.

After reviewing the differences between source your local project and the org, you’re ready to push or pull source. With source tracking, only the changed source gets pushed or pulled.