When using Salto with Git, it's common to wonder what is our prescribed or recommended Git branching strategy.

Salto does not have a typical branching strategy like GitFlow or org-based branching. Instead, Salto uses a hybrid of Git-based deployments and environment-based deployments.

Let’s explore each of these in general terms, not specific to Salto or any other deployment solution.

In a Git-based deployment model, changes made in Salesforce are committed to a feature branch. When you want to deploy those changes to the next environment in the pipeline, for example, UAT, you create a PR (pull request) between your feature branch and the UAT branch.

The PR allows developers to collaborate and review the changes. It also allows them to automate certain actions via the CI server, such as static code analysis, validation deployments against the target org, etc.

When the PR is approved and merged into the UAT branch, the CI server takes the contents of the UAT branch and deploys them to the UAT org.

To move those changes to another environment, for example, Production, you would merge the UAT branch into the Production branch or create a Release branch from Production and cherry-pick the commits you want to bring from UAT. The commit to the Production branch will kick off the CI server job, starting a deployment to the Production org based on the new changes committed to the branch.

The key factor in this model is that what’s in Git is what is deployed to the org. If something is not in Git, it will not be deployed to the org. Also, if some metadata is committed to Git but then changed in the source org, the deployment will only reflect the version committed to Git.

This is why this model is called Git-based deployments; deployments are done based on what is currently committed to a Git branch. This encourages thinking of Git as the source of truth.

In environment-based deployments, deployments are done based on the metadata that exists in a source org. An example of this model is Salesforce change sets. The metadata is extracted from one org, for example, your developer sandbox, and deployed to a target org, like, UAT.

There is no Git in between. All the changes are deployed directly between the two environments. Because Git is not used, teams using this model cannot review and collaborate on changes before approving them. There’s also no history of what has been done in the org, and teams need to rely on the org audit trail or go back to past tickets.

This model promotes the idea that the environment, or the org, is the source of truth for a given set of changes.

In Salto, we use a hybrid approach, combining both worlds. Here’s how it works:

First, Salto manages a copy of your environment’s metadata. This copy is refreshed frequently based on a user-defined schedule or manually on-demand.

When you want to move certain changes from your developer sandbox to the UAT org, you would create a deployment record in Salto.

This part of the process follows the EBD model, where you don’t have to commit changes to Git; instead, you go to the environment and manually select which changes you want to deploy to UAT.

This is beneficial because Salto can help you bring any missing dependencies or alert you of potential errors, something a Git-based deployment can’t do.

We also show differences between environments using a low-code UI which is easier to understand than Git’s text-based differences.

When the deployment record is created in Salto, we automatically create a PR in your Git provider. This is taken from the GBD model and allows your team to review and collaborate on the changes.

Also, you can configure your CI server to know when Salto creates a PR, and you can automate certain actions, such as a validation deployment against UAT and running all tests. This is again taken from the GBD model.

You can also add new metadata or changes to the deployment record in Salto. We will automatically update the PR, kicking off any automation you have configured.

Merging the PR against the destination branch does not automatically deploy those changes to the UAT org (unlike what you’d expect in the GBD model). Instead, Salto will allow/disallow to deploy based on the branch protection rules defined in the git provider.

Those rules can include one or more approvals from teammates and/or successful automatic checks.

Deploying from Salto lets you benefit from all the features we have for environment-based deployments, such as calculating missing dependencies, viewing differences in our low-code UI, validating your metadata, and providing better error messages than those provided by Salesforce.

Once you deploy the changes from the Salto UI, we help you easily commit those changes to Git, another feature of the GBD model.

This table summarises which areas belong to which deployment model.