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 version of your files, it will automatically change the file on your desktop to exactly the way it was when you committed the version. If you jump back to the most recent version, Git will quickly change the file back to the most recent commit. Make sure the text editor you are working with is smart enough to reload the text file in the event Git switches it to a different version.
What is GitHub?
GitHub is a website that will host a cloned version of your repo in the cloud. Git has built in syncing functionality to push and pull your files and commit logs to git repos in the cloud, which is similar to the way Salesforce DX will push and pull your metadata to a Salesforce org.
Websites such as GitHub are often called "remote" sites when you are using git tools so you can tell the difference between what is on your desktop and what is in the cloud.
Using GitHub for Collaboration
Of course, syncing your repo up to the cloud helps you backup the files in the event anything happens with your desktop. But, the main purpose of GitHub is for you to make your repo publicly available for others — including the full history of your commit log. This allows for collaboration among many developers on a single project.
Be sure to check the privacy settings of your repo in GitHub if you do not wish to expose your projects to the rest of the world.
Because the majority of developers will be joining the project by first finding it on GitHub and cloning the repo to their local desktop, GitHub is often referred to as "origin" in commands that sync the repos. This will be the case even if you started your project locally and then later pushed it to GitHub.
Anytime you think of "origin" in the context of Git, you are most likely thinking of the remote copy of your repo that lives in the cloud.
Other Key Salesforce DX Terms to Know
Branches
In the timeline of your commit log, you are able to "branch" off at any time to work on your own features separately from the work that has already been done. You will name the branch something related to the function on which you will be working.
If you start doing work and decide the changes you have been committing are not working out, you can delete the branch and it would be like changes never happened.
If you are finished with your work and want your commits to be available to the rest of your team, you will push the branch up to remote GitHub. This will replicate the branch up in the cloud and it will then become visible to everyone else working on the same repo.
Merge
When you encounter a branch of new commits on a remote repo, you have the ability to merge the branch into the one on which you are currently working. When this happens, Git will incorporate the changes from the foreign branch into your branch and merge the timelines back to a single point.
If Git detects the same lines of code have been edited in both branches since the last common commit, it will stop the merge and flag the lines as a conflict. At that point, you will have to use specialized tools to examine the conflicts, decide which version "wins" over the other, and then let Git know you have resolved the conflict so it can try to merge again.
Main or Master Branch
Every repo will have a main branch that is created by default when you first initialize the repo on your folder. This will also be the default branch that is downloaded from the origin when you first clone a remote repo to your desktop.
This main branch has historically been known as the "master" branch, but recent discussions in diversity and inclusion training have questioned the appropriateness of this term. While you will still see the term "master" in most documentation, we strongly recommend using the word "main" instead.
Your main branch will often be considered the gold master of your repo and will often require a review process before you are allowed to merge back into it.
Practice Using Salesforce Version Control with SFDX
This should give you a good foundation on what version control is and the core concepts you will be exploring with it. It is a very difficult skill to master, but you gain a lot of benefits.
Take a look at the Dreamhouse project that Salesforce hosts on Github. View the project’s commit history to see when was the last time the project was updated, and look at a single commit to see what was specifically changed at that time.
When you are ready to dive into version control, clone the project to your desktop, create a branch, make a change, and then commit your change to your local machine.
In our third and final part of our DX for Admins series, we will explore the concept of a scratch org and how you can use it to build up your DX project.
Salesforce DX Resources
Contact CRM Science Salesforce Consultants
Salesforce orgs at enterprise level companies and nonprofit organizations often require complex changes that go beyond resources like Trailhead that are available to Salesforce administrators. Salesforce DX is a great solution for Salesforce awesome admins looking to make declarative changes to Salesforce orgs. However, complex configuration changes often require expert consultation and development from Salesforce-recognized partners.
Contact CRM Science, a Salesforce Gold Consulting Partner, to discuss your most puzzling Salesforce challenges and strategic projects.
