Beginner 15 min read

Git Basics for Salesforce Developers

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

  • Perform the core Git workflow: branch, commit, push
  • Explain why .gitignore matters for a Salesforce DX project

Prerequisites: Source-Driven Development with the CLI

The core loop

The everyday Git loop is: branch (create an isolated line of work), commit (snapshot your changes with a message), and push (send those commits to a shared remote, like GitHub). git status and git diff are the sanity checks you'll run constantly before committing, to see exactly what changed.

.gitignore in an SFDX project

A default Salesforce DX project ships with a .gitignore that excludes local-only files — .sfdx/, .sf/, scratch org auth files, node_modules/ — so you never accidentally commit local CLI state or credentials. Only the force-app metadata source and project config files belong in version control.

Branch, commit, push

git checkout -b feature/opportunity-trigger
git add force-app/main/default/classes/OpportunityTriggerHandler.cls
git commit -m "Add Opportunity trigger handler"
git push origin feature/opportunity-trigger

This is the everyday loop: branch off, stage only the files you actually changed, commit with a clear message, and push the branch for review.

Exercise

Write the Git command to create and switch to a new branch named 'feature/security-course'.

Show hint

git checkout -b <branch-name>

BASH

Git Basics for Salesforce Developers — Quick Check

1. Which command both creates a new branch and switches to it in one step?

2. A default Salesforce DX .gitignore is intended to exclude local CLI state like .sfdx/ from version control.

3. Which command sends your local commits to a shared remote repository?

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

Git tracks every change to your local metadata source as commits, letting a team work in parallel on separate branches instead of fighting over one shared org — the same discipline you'd use on any other codebase.

Log in to track progress
← Source-Driven Development with the CLI Branching Strategies for Salesforce Teams →