Design Patterns for Salesforce Git Branching Strategies

Git branching strategies for Salesforce CI/CD are critical to a successful CI/CD implementation and a requirement to practice Continuous Integration in Salesforce.

In this article, I will discuss some common branching patterns and how they fit (or not) in the world of Salesforce development and DevOps.

Git-based Salesforce deployments

Git branching strategies are only needed if you are doing git-based deployments. What does that mean?

A Git-based deployment is a deployment where the metadata to be deployed is stored in a Git branch. Rather than taking metadata from one org and directly uploading it to another org (this is how Change Sets work), you make those changes in a Git branch and use sfdx (via a CI server) to deploy the entire contents of the branch to another org. This works because what's in the Git branch is an sfdx project.

Components of a Git-based deployment

To make Git-based deployments possible, you must have the following:

• an sfdx project+ your changes are committed to a Git branch
• A Continuous Integration (CI) server is connected to your Git repository
• The CI server executes sfdx commands against the sfdx project stored in Git
• These commands deploy the metadata to another Salesforce org

What are the benefits of Git-based deployments?

The main benefit is your Git branch represents the desired future state of production. This, in turn, allows for the following:

• Collaboration and visibility with GitHub (or BitBucket, GitLab, etc.)
• Easy to see the difference between the current state and desired state
• Enables Continuous Integration
• Provides a detailed audit or log of changes made to the org

Git-based deployments are great, but they come with a lot of challenges, as we'll see next.

What is a Salesforce Git Branching Strategy?

One of the main problems with Git-based deployments is they open a big can of worms and make your process (initially) more complicated.

Once you start doing Git-based deployments, you must answer these and many other questions:

• Does the main or master branch represent what's already deployed to production?
• Do we create feature branches off of main?
• Do we use feature branches at all?
• Do we have one git branch per Salesforce sandbox?
• How to we deploy a git branch to another Salesforce org?
• How does the sandbox strategy affect the git branching strategy?
• How often do we merge into main?
• How and when do we deploy to production?

How you answer those questions becomes your Git branching strategy. So in that sense, a Git branching strategy is your defined pattern for managing Git branches, when to merge them, what they represent, etc.

A Git branching strategy is your defined pattern for managing Git branches, when to merge them, what they represent, and more.

Sandboxes vs. Git branches

Before we look at the patterns for managing Git branches, I think it's useful to talk about sandboxes and how they are, in some ways, a way of branching.

A Git branch starts off as a clone of another branch. For example, we might create a branch called staging that starts exactly the same as main. Over time, we add commits to the staging branch, and it starts diverging from main.

In a way, the staging branch now represents the desired state of the main branch when they are eventually merged.

Do you see any similarities with sandboxes?

Similarities between sandboxes and Git branches

The lifecycle of a Git branch sounds a bit similar to a Salesforce sandbox, for example:

• Sandboxes are always cloned from another org (production or another sandbox).
• We develop new features in that sandbox that we eventually want to move to production
• The sandbox, like a Git branch, diverges from its source org over time as we make new changes.

There are obviously some major differences.

Differences between sandboxes and Git branches

Some differences include the following:

• Sandboxes take way longer to be created compared to a Git branch (less than a second)
• Sandboxes are never merged into another org, rather, their metadata (or a subset) is deployed to a target org.

Should sandboxes be used as branches?

Now that we understand the parallels between Git branches and sandboxes, it's worth asking whether sandboxes should be used as a way of branching or whether we need Git branches in the first place.

Sandboxes have (more or less) the same purpose as Git branches in traditional software development. They allow for isolated development of new features, isolated testing, release testing, etc.

The concept of a sandbox doesn't really exist in traditional software development, because in that case you use Git branches. The closest thing to a sandbox in traditional software development is a staging environment. For example, I may have HappySoup.io as production and staging.happysoup.io as a staging environment, where I give can give users the opportunity to test new features before they are released to production.

What are we talking about now?

I know I went on a tangent here with this discussion on git-based deployments and sandbox vs. branches. However, this was necessary to establish two points:

1) Git branching strategies are only needed if you are doing Git-based deployments; they are meant to answer many questions that arise from deploying in this way.

2) Git branching in Salesforce is a little awkward because sandboxes already provide a (poor man's) mechanism for branching, so when thinking of Git branches, it's impossible not to think about how they relate to your sandbox strategy.

With that out of the way, let's finally explore some Git branching patterns.

Salesforce Git Branching Patterns

First, I'm going to explore some general patterns around Git branches, and then we'll look at specific Git branching strategies and we'll see how those patterns are used in those strategies.