Navigating the world of Salesforce development can be tricky, especially when it comes to managing your entire codebase as a team. If you’re new to version control it’s likely you’re thinking about which Git branching strategy to adopt. Choosing the right one is key to keeping your team efficient and your projects on track.
In this article, we’ll explain why selecting a branching strategy is important and also look at the different approaches you can choose for your team. Hopefully one will resonate as an approach to bring your Salesforce DevOps to life — or continuing evolving it!
Why do I need a branching strategy?
Version control is a fundamental building block of any DevOps architecture, Salesforce or otherwise. So it’s important to choose a branching model that fits your needs as a business, and as a team delivering change to that business. The right branching strategy sets your DevOps process up for success in a number of ways:
Defined rules: It helps set up some rules for different types of changes (like a standard feature vs a production-critical hotfix) and how they interact with each other to keep the process flowing and start building greater momentum with your feature delivery.
Easy integration: Knowing how your branches and sandboxes interact with each other and identifying key stages of integration can also help shape code quality and automated testing to build up confidence throughout the workflow, leaning into the ‘shift-left’ mindset for testing.
Increased visibility: With known rules and expectations around how branches are created, merged and propagated, everyone in the team has the baseline knowledge for how any change will flow through your release pipeline.
Full team collaboration: This doesn’t only extend to technical tool collaboration, but also the right communication and collaboration you expect from team members when handling different scenarios — an innocent-looking commit into the wrong place could have big consequences!
Creating and maintaining a branching strategy will add an additional layer to your usual sandbox management, but the benefits it unlocks will far outweigh the extra effort involved.
The benefits of version control
Version control has underpinned software development on other platforms for a long time. But until recently, Salesforce teams were behind the curve when it came to adopting version control. This was due to the platform’s unique “clicks not code” approach to org configuration, which reduces the need for complex dev tooling.
As the Salesforce platform has continued to mature and offer more complex functionality, the value of version control has become increasingly apparent, and we’ve seen the transition to source-driven workflows become more common. Our latest State of Salesforce DevOps report, based on a survey of over 1,200 Salesforce teams, found that 86% of respondents were already using version control or plan to adopt it over the next year.
Bringing version control into your process helps realize the following key benefits:
Versioning: Structure for tracking changes to files over time (these could be text files, source code, Salesforce metadata, or even config data like CPQ).
Traceability: Visibility into the history of those changes, who made them, and how they propagated through to different branches — a much greater level of insight than in Salesforce natively!.
Collaboration: Parallel development streams throughout the team without impacting other work, and a place to propose, review and merge changes with full visability.
Automation: The ability to build in automation and move away from manual deployment practices.
With traditional software development the concept of a “sandbox” isn’t anywhere near as common as it is in the Salesforce ecosystem, but understanding how version control and a great branching strategy builds way above and beyond what sandboxes can provide is key.
Salesforce also gives much more flexible and disposable areas to work in via scratch orgs, and are a key example of a concept that’s built around leveraging code stored in version control as the source of truth, which can be used to start new work from or conduct testing.
Git is the de facto version control for Salesforce
There are many types of version control out there, but Git is the most popular one used by Salesforce teams. Git provides teams with the ability to separate out multiple streams of development and avoid stepping on each other’s toes by making changes in isolated branches, instead of in shared sandboxes.
Git also provides a shared source of truth for all code changes. Each repository has a “main” or “master” branch, which holds the current production-ready versions of all files. By having everyone work from this single starting point, and tracking all changes across the codebase, it’s easy for teams to have a shared understanding of what’s approved and reduce the chances of code duplication.
However, this depends on the branching strategy you choose because having visibility and understanding across the codebase is really crucial. It might be that you actually need to start work from an earlier point, such as a long-term project or Gitflow way of working.
Git gives you a structured way to review changes via pull requests and integrate them together before release, as well as dealing with any conflicts that may arise. Continuous integration, and as a result continuous delivery, is built on top of version control — it’s not possible without it. So version control is completely foundational to any DevOps process.
Branching strategies
A branching strategy sets the rules for how you use and manage branches when developing features in version control, but there’s no one model that suits every team perfectly, and usually they’ll need tailoring over time as you continue to scale. Picking the right strategy for your team will depend on many things, like:
Team size: Larger teams are more likely to have a larger variety of roles that need to interact with the version control strategy, and this may have an impact on which model is right for you.
Team structure/complexity: More complex models will take longer for newer and less technical members of the team to get their heads around.
Desired release cadence: There can be business reasons that dictate a particular release cycle. Branching strategy allows you to manage those requirements.
Current workflow: In many ways, switching to using version control is an opportunity to reshape your workflow. But it makes sense to start with a branching strategy that more closely resembles your existing workflow. How are your environments set up? How many sandboxes? How might these environments correspond to your branches?
Git as a backup
This strategy is sometimes seen as the first step teams take into version controlling their metadata. They set up one branch per environment, and start pushing metadata from their Salesforce orgs into the branches, often with an automated CI job.
While this is a decent first step towards getting metadata into Git, the development life cycle is not really driven by version control. Version control isn’t acting as a source of truth here, just a record of the changes that have happened. To be clear, this is still useful — but to get most of the benefits of Git you need to ensure that once changes are developed, they go into version control to allow them to flow between environments smoothly.
For example, in this flow you can’t easily accommodate parallel development streams on multiple features. There are no pull requests in this model, which would allow you to easily integrate peer review into the workflow. To make things worse; because you’re not regularly deploying from version control into your environments, you probably won’t have confidence that you could roll back a release by deploying an older revision from version control.
Version control is first and foremost designed to help teams create, track and deploy new features. It shouldn’t be seen as a full backup of your Salesforce environments for disaster recovery purposes — that’s what your backup solution is for in your overall DevOps lifecycle. The other branching strategies outlined here are much better suited to helping you realize the true benefits of version control!
Feature branch model
This is the simplest model that actually uses Git as part of your development process, rather than just a lightweight backup. Some teams will have good reasons for preferring more complex branching strategies, but the simplicity of the feature branch model makes it a good starting point.
With a feature branch strategy, the latest version of your metadata is stored on the main branch, and it should ideally always be in a state that’s ready to release. This is your only long-lived, permanent branch. When someone wants to develop a feature or a fix, they create a new branch from main, and work on that branch. Once the feature is done, the branch is merged back into main.
Ideally, in this model, feature branches should be as short-lived as possible and deleted after use for general tidiness (another great example of where scratch orgs could fit nicely!). Larger features should be sliced into smaller deliverables and implemented one at a time. This reduces the length of the feedback cycle, and reduces the chance of merge conflicts.
The main branch is usually deployed automatically to a staging environment whenever it is updated, using a CI process. This means that the latest version is always available for testing on the staging environment. Once you’re happy with the version on staging, a manual deployment from main to the production environment releases the changes to your end users. Before deployment to production, you could (and should!) also deploy to a UAT or QA sandbox for further testing.
Protected master branch model
This strategy is similar to the feature branch model, but adds one long-lived branch for integration, before merging into main (or master as it’s also known). In this model, the main branch isn’t updated until everything is tested and ready to go. Main is a more protected source of truth, as only work that has been fully tested in UAT makes it into the branch.
One drawback with this model is that it’s not possible to propagate just a subset of changes if some others aren’t ready yet. If some work has been tested and approved in UAT, but other things aren’t good to go yet, you can’t easily cherry pick what to promote to main. You’d need to revert features that aren’t ready from the release branch.
A lot of the teams don’t like this model because of the inflexibility to pull changes, or the complication of trying to only deploy certain elements.
Expanded branching model
This model adds a few extra long-lived branches which correspond to your integration and UAT/QA environments. Once a feature branch is complete, rather than merging straight into main, you merge into your integration branch. To promote any changes from there that you’re happy with, you would merge into the UAT branch, and then onwards into main.
Taking this approach allows more fine-grained control of which changes get through to each environment and allows for isolated reviews of changes on a per-request basis. The expanded branching strategy works well for teams that are more concerned about gating and quality control than releasing as frequently as possible.
Pipelines, Gearset’s Salesforce CI/CD solution builds on the foundations of this model by providing some extra benefits. It uses “promotion” branches to keep feature branches from being “polluted” after solving merge conflicts. Pipelines also allows releases (bundles of features) to be created and deployed. This way of working gives much more flexibility at every stage of your workflow, and is also a much more palatable concept to those used to change sets moving from environment X > Y > Z.
Gitflow branching model
This is one of the more well-known and established strategies used in general software engineering. It was created back in 2010 and includes a few more moving parts and unique elements that form the expected way of working.
One of the most important aspects of this model is a long standing “develop” branch that sits before main/master. This is where new features are cut from and merged back into, allowing in-flight work from other developers to be included as building blocks without having to make it all the way to production. Whilst this does allow work to be built on earlier, it does mean you lose the feature isolation you get with other models like the expanded branching model.
There are then multiple variations you could make to Gitflow to make sure it fits with your team, but usually, in Salesforce development, develop could feed multiple sandboxes as part of your release pipeline. This is shown as Integration in the example above, but could extend to UAT/Staging and other sandboxes that don’t have a dedicated branch. Then, once you’ve collated and tested the features to deliver, a “release” would be carved and merged into main/deployed to production.
But what if a hotfix is required in production and we’re stuck in a develop testing cycle with lots of features we don’t want to drag forward? That’s where the separate workflow for hotfix comes in; a specific branch to add a hotfix could be carved from main and merged back in, separate to the in-flight development work (which is usually part of a dedicated sprint). This means there’s a quicker route to fix burning issues in production, but includes the necessary step to sync it back into develop as it could affect ongoing work.
Gitflow can be a really effective model if you have a set cadence of releases. It’s also great when the team is accepting of some of its core concepts like branching from develop and creating release branches to move forward and everyone tags appropriately. This strategy works best when there’s an understanding of the cross synchronization requirements to keep main and develop in sync with each other.
What are the pros and cons of each branching strategy?
| Branching Strategy: | Pros | Cons |
|---|---|---|
| Git as a Backup | Easy way to get started with source control. Gives you a better record of the changes compared to in-org changes or deployments without source control. | Not really leveraging source-driven development or any of its benefits (parallel working, PRs, gates). Branches are very likely to drift and could be difficult to unpick. |
| Feature Branching | Simple to get started and minimal branches so a great strategy for smaller teams starting out. Makes version control the source of truth and gives access to parallel working, automatic deployments and other benefits. | Main branch is less aligned to production because of interim sandboxes and testing cycles. Lacking quality gates and can be complex to scale depending on size of the team and release cadence. |
| Protected Master Branch | Gives you an extra quality gate before main to test groups of features. Main is genuinely aligned to production and not “muddied” with untested work. | Separating good from bad in the “middle” branch can be more complicated. Could cause a ‘queue’ of work depending on testing speed. |
| Expanded Branching | Splits out a branch per sandbox so easier alignment and visibility on overall flow. Granular control of which feature goes where & quality gate per sandbox. | More branches to manage and maintain overall, so could be slower depending on gates. Can be difficult to build on in-flight work early on without risking dragging extra items forward. |
| Gitflow | High degree of control to build on early functionality, segregate tested/untested features, and utilize hotfix paths. Very well-documented and used throughout wider software engineering industries so a proven model. | Depending on your org structure there can be lots of moving parts to maintain and can be difficult to quickly move individual features through. More complicated with releases/hotfixes to manage compared to other strategies. |
Which is the right strategy for your team?
Your choice of branching strategy should align with the priorities of your team and consider the pros/cons listed above: The branching strategy you choose should align with the priorities of your team and teammates should be on board with the benefits of each one:
Git as a backup: Consider this strategy if your team is completely new to Git and needs a gentle learning curve. This is not a long-term strategy to adopt.
Feature branch model: Another great option for teams new to Git or those wanting to rapidly iterate and prioritize agility — Gearset uses this strategy and it allows us to release multiple times a day. If your process requires more stage-gates and checks along the way, this may not work for your longer dev cycles.
Protected master branch model: Teams that want to emphasize rigorous testing over fast delivery might choose this model. But this model creates a queue where items requiring longer test cycles can hold up other changes until promoted, and a learning curve to only take specific elements forward.
Expanded branching model: This choice is the best choice for teams that want smaller releases with multiple stage gates for different types of testing. It allows for an asynchronous approach to releases, because pieces of work can be promoted through your environments individually. So your team can say things like, “JIRA 34533 is in UAT awaiting sign-off for release to production”. If you need to consistently build on existing work or are conscious of how many stages there are in your release flow and their need for synchronization, there may be better alternatives.
Gitflow branching model: This option is usually more suited to larger teams who need to utilize a stricter and more predictable release process. It favours building on existing work before it is fully live in production and releasing as larger tested chunks. If you’re after a more rapid-release and isolated feature approach, this may not be the right strategy to pick up.
Where can I learn more?
This has been very much a whistlestop tour of a few branching strategies. As we’ve seen, there’s no one-size-fits-all — the key is to find the unique process for your team. If you’d like to learn more, check out our webinar with a deep dive into Git for Salesforce.
To get specific recommendations for your team, take our free DevOps Assessment, which is a great way to understand your current strengths and weaknesses, and identify next steps.
For more about branching strategies and how you can implement version control as a foundation for CI/CD, download our free whitepaper.
