Salto's Git Branching Strategy

An explanation of Salto's approach to version control

Support avatar
Written by Support
Updated over a week ago

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.

Git-based deployments (GBD)

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.

Environment-based deployments (EBD)

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.

Salto’s deployments, a hybrid approach

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

Change selection

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.

Pull Requests and Automations

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.

Version Control

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.



Deployment model


Selecting which metadata to deploy

Manually in the Salto UI


Automatic dependency resolution, change validators, admin-friendly comparisons, etc.

Reviewing changes and collaboration

Salto automatically creates a PR in your Git provider


Enjoy all the features of PRs, like context-based comments, reviews, etc.

Automating actions such as validations, static code analysis, etc.

Via your CI server


You are not limited by what Salto can automate. Automate anything you want via the CI server.

Deployment to the target org

Manually in the Salto UI (or automated via the Salto SaaS CLI)


We provide a better overview of what is being deployed and provide better error messages (though hopefully, you won’t see any!)

Did this answer your question?