Source Tracking
By the end of this lesson, you'll be able to:
- Explain what source tracking is and what problem it solves
- Pull changes made in an org back into local source files
- Push local source changes into an org
Prerequisites: "Scratch Orgs"
The problem: two places changes can happen
A developer might edit an Apex class locally in VS Code, or make a quick configuration change directly in the scratch org's Setup UI — both are legitimate ways of working, but they need to stay in sync with each other, or changes get lost.
Pulling changes from the org
sf project retrieve start --target-org my-feature-orgIf a quick change was made directly in the scratch org (say, adjusting a field's label through Setup), retrieve pulls that change down into the local source files — now trackable by Git, exactly like any other file change (Module 14).
Pushing changes to the org
sf project deploy start --target-org my-feature-orgThe reverse direction: any local file changes (a new Apex class, an edited trigger) get deployed into the scratch org. Source tracking specifically means the CLI tools can detect which files actually changed since the last sync, deploying only what's different rather than the entire project every time.
Exercise
As a comment, describe the two commands you'd run, and in what order, to make sure a local trigger edit and a Setup-UI field label change both end up captured correctly.
Show hint
One direction pulls the org's changes down; the other pushes local changes up.
Source Tracking Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Source tracking automatically detects the difference between a scratch org's current state and local source files, letting changes flow reliably in both directions.