Beginner 15 min read

Local Development Workflow and Source Control Basics

By the end of this lesson, you'll be able to:

  • Describe the standard Salesforce DX project folder structure
  • Apply basic Git practices to a DX project
  • Describe a typical feature-branch workflow for LWC development

Prerequisites: "Creating, Deploying, and Retrieving Components"

The Standard Project Folder Structure

force-app/main/default/
├── lwc/          ← every Lightning Web Component, one folder each
├── classes/      ← Apex classes
├── objects/      ← custom object metadata
├── triggers/     ← Apex triggers
└── ...

This layout is consistent and predictable across virtually every Salesforce DX project you'll ever open.

Git Basics for a DX Project

Source format — one human-readable file per component — is specifically designed to work well with Git: meaningful diffs, mergeable changes, unlike the old zipped metadata format most Change-Set-based orgs still rely on. A typical .gitignore excludes .sfdx/ (local CLI session state) and .localdevserver/ — neither belongs in source control.

A Typical Feature-Branch Workflow

  1. Create a feature branch off main.
  2. Develop against a scratch org or sandbox.
  3. Commit source-format changes incrementally, in small logical chunks.
  4. Open a pull request for review.
  5. Merge once approved.
  6. Deploy the merged code to the next environment stage.

This mirrors general software engineering practice, applied directly to Salesforce.

Why This Matters in Real Projects

Enterprise Salesforce teams increasingly run real CI/CD pipelines — automated validation and deployment triggered by a pull request or merge (Module 20 touches this). None of that works without disciplined source control practice at the individual-developer level first.

Exercise

List two things that typically belong in a Salesforce DX project's .gitignore file.

Show hint

Think about local, machine-specific state that shouldn't be shared.

BASH

Exercise

Challenge: describe, as a comment, a typical feature-branch workflow for building a new LWC on a team, from branch creation to production.

Show hint

Cover branching, development, review, and promotion.

BASH

Local Development Workflow and Source Control Basics Quiz

1. Where do Lightning Web Components live in a standard DX project?

2. Why does source format work well with Git, compared to the old zipped metadata format?

3. The old zipped metadata format is generally considered more Git-friendly than source format.

4. What typically belongs in a DX project's .gitignore?

5. Two developers each work on a different LWC component in the same sprint. Why do their changes rarely conflict in Git?

Log in to submit the quiz and save your score.

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 format was specifically designed to work well with Git — one file per component, meaningful diffs — and a disciplined feature-branch workflow is what makes real team-based Salesforce development possible.

Log in to track progress
← Creating, Deploying, and Retrieving Components Exercise: Create, Deploy, and Test an LWC in a Real Org →