Newer Version Available
Pulling and Pushing Changes Identified by Source Tracking
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 /WidgetClass.cls-meta.xml
5Local Add WidgetClass ApexClass /WidgetClass.cls
6Remote Changed Widget__c CustomObject force-app/main/default/objects/Widget__c/Widget__c.object-meta.xml
7Remote Deleted Widget__c.all ListView force-app/main/default/objects/Widget__c/listViews/All.listView-meta.xml
8Remote Add WidgetPermissions PermissionSetAs 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 resolving conflicts, see Resolve Conflicts Between Your Local Project and Org.
1sfdx force:source:pull -u DevSandboxAfter 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 /WidgetClass.cls-meta.xml
5Local Add WidgetClass ApexClass /WidgetClass.clsNext, push your local changes. After pushing, other developers see your changes in the org as remote changes.
1sfdx force:source:push -u DevSandboxRun source tracking again.
1=== Source Status
2No results foundSource tracking reports no results, indicating that your local project and the org are synchronized.