This is why Git cannot be the source of truth for your Salesforce org

I get asked this question a lot: Should git be the source of truth of my salesforce org?

I like to answer that question with another question: the source of what truth?

See, not everything in your Salesforce org is exposed via the Metadata API, which means it cannot be retrieved and stored in version control, and changes to those types must be done manually.

Salesforce maintains a list of such metadata types here

If your org is not using any of these metadata types and has no plans to ever use them, then yes, git can be the source of truth for your org.

But if you are using any of those metadata types, the reality is that there's stuff in your org that cannot be in git and cannot be deployed via a git-based deployment.

Even if all metadata types were supported, the question still stands: what truth?

Is your Salesforce org just a pile of metadata? No, it also has data, and many times, this data is reference data; data that control the run-time behavior of your Salesforce org.

This is the case of managed package apps like CPQ, nCino, etc., that use custom objects as metadata (likely because they were created before custom metadata types were created).

This is data that wishes it was metadata. Still, it isn't, so unless you are using something like Salto (which can translate reference data into metadata, seriously, we can), then that reference data is not in version control, which means git is the source of some truth in the org, not all of it.

In short, to make git the source of truth for your org, you must:

1- Acknowledge that it's the source of some truth, not all of it
2- Have the discipline to ensure that that subset of metadata is really only controlled by git-based deployments

Subscribe to become a Salesforce API and CI/CD expert