Pull and Push Changes Identified by Source Tracking

When you create a Salesforce app, you typically use both low-code and pro-code techniques. An example of low-code is creating a custom object directly in an org using Setup. An example of pro-code is creating an Apex class in your local project using an IDE, such as VS Code. As you work, source tracking identifies changes so you can keep the remote metadata in the org in sync with the source in your local project.

The process is iterative. First you get a status of the remote and local changes. If conflicts exist, you resolve them. You now must ensure that these changes exist in both the org and your local project. So you pull the remote changes so that your local project, and then your version control system, contains everything and is the source of historical truth. You push your local changes, such as Apex code, to the org so you can validate and test it. And you keep iterating through this process until you finish developing the Salesforce app.

Let’s look at some examples to see source tracking in action.

Say you run force:source:status and see local and remote changes.

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            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

As a best practice, pull changes and resolve conflicts before pushing your changes to the org. This practice helps other developers incorporate your changes and generally facilitates collaboration. For help with resolving conflicts, see Resolve Conflicts Between Your Local Project and Org.

1sfdx force:source:pull -u DevSandbox

After pulling source, run force:source:status again. Now, source tracking only reports your local changes because pulling updated your local project to match what’s in the org.

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

Next, push your local changes. After pushing, other developers see your changes in the org as remote changes.

1sfdx force:source:push -u DevSandbox

Run force:source:status again.

1=== Source Status
2No results found

The command reports no results, indicating that your local project and the org are synchronized.

Salesforce DX Developer Guide

Pull and Push Changes Identified by Source Tracking