Newer Version Available

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

See Changes Identified by Source Tracking

To see changes between your local project and target 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.
    1cd 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.
    1sfdx force:source:status -u 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.

1=== Source Status
2STATE                     FULL NAME          TYPE              PROJECT PATH
3──────────                ───────────        ─────────         ─────────────────────────────
4Local  Add                WidgetClass       ApexClass          ./classes/WidgetClass.cls-meta.xml
5Local  Add                WidgetClass       ApexClass          ./classes/WidgetClass.cls
6Remote Changed (Conflict) Widget__c         CustomObject       ./objects/Widget__c/Widget__c.object-meta.xml
7Remote Deleted            Widget__c.all     ListView           ./objects/Widget__c/listViews/All.listView-meta.xml
8Remote Add                WidgetPermissions PermissionSet

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 there’s 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 CLI automatically creates, deletes, or updates components when you push or pull source. In this case, the CLI encountered a change that it couldn’t automatically resolve. Before pushing or pulling changes, resolve the 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 source tracking doesn’t detect any changes, then the force:source:status command returns a statement saying No results found.

1=== Source Status
2No 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.