Cracking the Salesforce DevOps Interview—Part 3 (Git)

Written by
Pablo Gonzalez
Business Engineering Architect
April 18, 2023
min read

Table of Contents

View all guides


Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

This is some text inside of a div block.

Welcome to the 3rd part of our "Cracking the Salesforce DevOps Interview" series. 

In these series, I come up with sample interview questions I would ask if I was hiring for a Salesforce DevOps role.

In case you missed them, here are parts 1-2:

Sandbox Strategy Interview Questions

Salesforce CLI Interview Questions

This time, I ask detailed questions about using Git with Salesforce.

Let's get started.

Get Started with Salto

Everything you need for error-free Salesforce deployments

Try it free ≥Try it free ≥

1- When should you use a remote Git repository for Salesforce?

When using Git with Salesforce, you must initialize a local git repository on your sfdx project. Once Git is initialized, you can run commands such as git commit, git log.etc.

This can be done without your local repository being connected to a remote repository, such as GitHub, BitBucket, or GitLab.

So, when should the local repo be connected to a remote one? 

The remote repository is typically used for two reasons:

a) Backup

If your laptop crashes or gets stolen, you don't want all your Git history gone with it. By pushing changes to a remote repository, you have a backup.

b) Collaboration

When you use a remote repository, all developers can connect to it. This allows everyone to see everyone else's changes.

It also allows for Continous Integration because you can pull someone else's changes to your computer before you start working on a new feature, thus making sure your changes work alongside theirs. 

2- You have made several (uncommitted) changes to an apex class and decided to return to its previous version. What Git command can you use? 

The git stash command is a perfect fit for this use case.

Using git stash you can "stash" the changes you have made but haven't committed yet. Stash means putting them aside or discarding them but not deleting them.

You can give the stash a name, and later, if you want to, you can cover the changes. 

You can learn more about this command here

3- What is the difference between an org-based and a Git-based deployment?

An org-based deployment is one where the source of a change (say, a new apex class and a modified custom field) is a Salesforce org.

You deploy the changes to a new org by taking the metadata from the source org and deploying it to the destination org. This is the model used by change sets and other Salesforce DevOps tools.

In contrast, a Git-based deployment is one where the change source is a Git branch. 

For example, a developer commits changes to a feature branch. When the branch is merged into the development branch, the new or updated metadata is deployed to a destination org. This is the model used in CI/CD.

Fun fact: Salto's deployments are a hybrid of these two models. We take the best of both worlds. It's pretty interesting! 

4- What role does Git play in Salesforce Continuous Integration?

As explained extensively in this other article, Continuous Integration (CI) is the practice of committing changes to a shared branch as frequently as possible to ensure that your changes don't break other developers' work, and vice-versa.

With this said, Git is at the core of CI. Git is what allows you to see what other developers have changed and what will enable you to fetch their changes and integrate them into your local copy of the repository.

Without Git, you cannot practice CI. 

5- You just created a new validation rule. What commands from the Salesforce CLI and Git do you need to commit this to version control? 

This one is easy. First, make sure you master the Salesforce CLI

To retrieve the validation rule, you can run the following command:

sfdx force:source:retrieve -m "ValidationRule:MyRuleName"

Then, you can commit the change to version control with 

git add .
git commit -m "new account validation rule"

6- How do you ensure VSCode, Git, and your org are all in sync?

Imagine this scenario:

a) You have a validation rule in your org. This validation rule is also in your sfdx project in VSCode and in the Git repo. 

b) You edit the validation rule in the org but forget to retrieve the latest version of the rule using the Salesforce CLI.

c) Two days later, you change the rule directly in VS Code and forget to deploy it to the org and commit it to Git.

Now your org, the sfdx project, and Git all have a different version of the rule. 

How do you reconcile the changes?

You can use the source diff command to see how the validation rule differs between your org and VS Code.

Then, you’ll be able to see the diffs right within VS Code

To see the differences between the validation rule in VS Code and Git, you can use a VS Code extension called Git Lens. With this extension, I can see a timeline of changes made to the validation rule and how it's currently different from the last version I committed to Git. 

Once I can see all the versions, I can use a combination of Salesforce CLI and Git commands to ensure only one version exists across all three places.

The org comparison tool every admin needs

Have you ever seen XML-free org comparison tool?

Try it free ≥Try it free ≥

7- How do you decide what metadata to track in Git?

This question is about how much metadata you should store in Git. For example, do you download the entire Salesforce org and commit it to Git, or only the code-based metadata? Like apex classes, LWCs, etc.? 

I wrote about this in my CI/CD Checklist for Salesforce Architects

The key is determining how much complexity you want to deal with vs. how much metadata you are happy to be accountable for.

It's perfectly ok to decide that you will only track code-based metadata and that other metadata will not be tracked.

You can always add more metadata types as you get familiar with Git and the complexities of Salesforce metadata and deployments. 

8- Should you commit directly to a shared Git branch or use a pull request instead?

Using a pull request (PR) instead of making commits directly to a shared branch (for example, development) is a good idea because it allows other developers to review your changes and add questions or comments.

In Salesforce, you can also have a CI job run a validation deployment when a PR is created, allowing you to check if your changes are deployable.

If you commit directly to a shared branch and the changes are not deployable (i.e., you get a deployment error), you have to revert the commit, which can be complicated. 

9- How do you roll back to a previously known state using Git?

Let's say you've made 5 commits on an apex class, and you want to go back to commit number 3 and get rid of 4 and 5, as if they never happened.

How do you do this?

Here's one way

a) First, get the commit Id of commit number 3, let's say it is commit3id

b) Then, create a branch from that commit

c) git checkout -b [new-branch-name] commit3id

c) Now, go back to main

git checkout main

d) Finally, do a hard reset. This'll reset the timeline to commit number 3

git reset --hard [new-branch-name]

10- Can Git be the source of truth for your Salesforce org?

I answered this question in this short blog post and recommend reading it (if I paste it here, Google will flag it as plagiarism).

The long story short is that Git can be the version of some truth in your Salesforce org, but not all. It can also be the source of truth of specific changes in the org but not the source of truth of the current state of the org (as is the case with infrastructure as code in traditional software development).

This is because:

a) Not all metadata can be deployed via the Metadata API; some must be modified manually in Production.

b) Your org may also have configuration data, such as CPQ, which cannot be versioned in Git (unless you do this).

c) As long as Salesforce allows direct production changes, Git will always be behind.

And that's it! I hope you enjoyed this article! See you in part 4! 

Written by
Pablo Gonzalez

Pablo is a Business Engineering Architect at Salto. He is the developer of and has 11 years of development experience in all things Salesforce.

Written by