Lesson 3: The Seven Mismatches

Seven specific places where applying Git to Salesforce stops being inconvenient and becomes a predictable, repeatable failure, each with a real cost.

Start here

Each topic below covers a building block of this lesson. We recommend following them in sequence as each builds on the last.

Git tracks XML files, not the org's component graph. A field rename silently breaks 14 other components.

Admins change production; developers change sandboxes. Git knows neither, so drift compounds until a deployment clobbers something.

A clean Git merge can produce metadata that deploys successfully but leaves the org semantically incorrect.

Standard branching strategies assume environments are disposable and identical. Salesforce sandboxes are neither, and get expensive fast.

Salesforce validates dependencies, tests, and constraints before committing atomically or rolling back. Deploying is nothing like a file push.

Salesforce has no rollback. Restoring a broken production org means manually reconstructing prior state while users wait.

Git records authorship; compliance auditors need approval chains, deployment records, and out-of-pipeline changes, none of which Git tracks.