Version control is considered one of the most critical skills developers use when working on projects. There have been many tools and practices invented to help keep track of changes made while working and to allow teams to collaborate without stepping on each other's toes.
But, Salesforce administrators and developers have long been missing out on these types of tools as they build up their Salesforce orgs. Configuration items get deleted with no way of figuring out what used to be there. Multiple users in the same sandbox easily overwrite each other without even realizing it.
Version Control for Admins with Salesforce DX
In part 1 of our series, Salesforce DX for Admins: SFDX Basics, we learned that mostly all configurations Salesforce admins make on their orgs are saved as XML files. These files lived almost entirely on the cloud and were not easy to get access to. These restrictions are what made version control nearly impossible for many years.
With the introduction of Salesforce DX and the ease of syncing files from the org to the developer's desktop, Salesforce admins now have complete access to these files and the ability to do anything they want to them. And, now they can begin to use the version controlling tools developers have been using on other technology platforms for years.
Version control is not the easiest skill to master, so in this part in the series, we will give you a high level overview of the version control tools you’ll encounter and what to expect when using them.
You can access the other parts to this blog series here:
What is Git?
Git is a freely available application that has become the industry standard for version control in the past decade. You may encounter other tools such as Mercurial, SVN, or CVS, but Git has dominated this space for a while now and shows no signs of being replaced any day soon.
The core function of Git is to turn any folder on your desktop into a code repository, or a "repo" for short.
Once you create a repo on your desktop, you have the ability to save versions of your files in that repo at any point in time. This save is called "committing" your files to the repo.
You will have to write a note when you commit so that the repo can keep an ongoing log of all your changes. These logs can easily be displayed to you as a timeline, so you can always see:
Who made the changes
When they made the changes
What exactly what changes were made and committed at that point
Git also turns your desktop into a virtual time machine. When you request Git to switch to a different versi