What’s the difference between ‘source control’ and ‘version control’?

Tl;dr — Both terms are valid, but there are good reasons why ‘version control’ is used more often in the Salesforce world.

Do you ever wonder which term you should use: ‘source control’ or ‘version control’? You might come across both, and they’re often used interchangeably. But are they the same thing? Is one more ‘correct’ than the other? Does it depend on the context?

Having multiple terms can be especially confusing for anyone learning about version/source control for the first time, and plenty of folks in the Salesforce community are still relatively new to the concept. In this post, we’ll look at each term and why you might want to use one or the other.

Source control: is it just about code?

Some argue that ‘source control’ is specifically about source code, while ‘version control’ is a more general term that applies to any set of files.

Does that make it wrong to talk about ‘source control’ in relation to Salesforce metadata that’s developed declaratively — flows, profiles, layouts, and so on? Do admins, configurators and no-code developers contribute to your ‘source’, or are they doing something fundamentally different?

Of course it depends how exactly you define ‘source’, and that’s an interesting question in the context of a low-code platform like Salesforce. Some definitions of source code exclude anything created with clicks. The Linux Information Project, for example, argues that source code “is the version of software as it is originally written (i.e., typed into a computer) by a human in plain text.”

But other definitions make room for declarative changes to be considered ‘source code’, including Richard Stallman’s definition: “The ‘source code’ for a work means the preferred form of the work for making modifications to it.” That could easily describe changes made in Salesforce using clicks not code. And of course, those changes are represented as XML in your Git repository — just like all other metadata, including Apex.

When people use the term ‘source control’ they’re rarely just referring to a repository of Apex classes. Usually they mean all of their Salesforce metadata.

Version control: a neat description of the solution

While ‘source control’ is widely used, ‘version control’ is the term that appears much more frequently — especially in the Salesforce world. Perhaps that’s because it’s intended as a general term that applies to everything Salesforce teams work on: both declarative and programmatic development.

But arguably there’s something else, too. The term ‘version control’ is a neat description of the problem being solved.

Developers turn to version control because it makes it easy to track changes to project files. Teams of developers — including low-code and no-code teams — need version control because without it they end up overwriting each other’s work all too easily. The fundamental problem is losing track of the different versions of files, or struggling to merge different versions together. Version control is what helps you identify which bits of work are the latest changes that can be merged together safely.

It’s because ‘version control’ captures this idea that I tend to use it more often than ‘source control’. In my view, ‘version control’ describes the concept more helpfully. But I haven’t committed entirely to one term or the other — it’s good to branch out every now and then.

Are you in control?

Clearly, the common denominator for both terms is ‘control’, so all this really boils down to what you want to emphasize. Is it that you’re on top of your source code? Or is it that you’ve solved the problem of having multiple versions in a chaotic mess? Either way, you don’t want to be out of control.

Stay in control by making sure you and your team have the right skills to succeed with DevOps. If you’re getting to grips with Git and figuring out how you can apply it to Salesforce development and releases, you’ll find everything you need in the free courses on DevOps Launchpad — whether you need an introduction to version control or a deep dive into the pros and cons of different branching strategies.