Hello there!

Short description

I would like to describe my favourite top 3 git branching strategies for Salesforce.
They are applicable in both cases, working alone or with 100+ developers.
I’ve listed the pros and cons of each branching strategy to help you decide which suits your needs.
But before I do that, let me explain the background of why you would need a Version Control System at all for Salesforce.
If you already know that, feel free to skip that.

Why do you need Git for Salesforce?

There are many reasons why having a version control system like git and a change management process is a must-have for a company using Salesforce. Here are some of the most important reasons:

1. Manage and track changes – Companies rely on code to create their products and services. Having a version control system helps ensure that code is properly managed and tracked, making it easier to identify and fix errors.

2. Test your code – A change management process helps ensure that changes to code are properly tested and approved before they are implemented. This helps avoid errors and disruptions to products and services.

3. Create release process – Businesses most probably will constantly be evolving and want developers to release new products and features. Having a version control system and release process in place helps ensure that code is properly moved across orgs up to Production at a fast pace and keeping quality high.

4. Enforce standards – Technology companies often have multiple teams working on different parts of the same codebase. Having a version control system and change management process helps ensure that code changes are appropriately coordinated between teams, avoiding conflicts and disruptions. Otherwise overwriting each other will happen on daily basis.

Branching Strategy for Salesforce

I chose 3 branching strategies with which I was working so they were put into practice, not only looking good on paper as a concept.
Below branching, strategies are aimed at metadata without unlocked/managed packages.
If you are using packages I guess you will choose something more oriented at artefact so maybe a casual gitflow?

Assumptions

• 3 non-prod sandboxes
• development is done on sandbox(es)/scratch orgs which is not presented on the graph as it is not part of CICD
• merge commit(s) happens when code is successfully deployed, NOT before deployment – this ensures we are not "breaking" branches that easily
• all changes should be propagated through the version control system and all sandboxes up to PRD in the correct order (no YOLO changes in PRD)
• flow of promoting changes is the following:

Single long-live branch

Pros:

• simple to learn
• enabling true Continous Delivery/Deployment
• good for small projects
• aimed to support small and often incrementations
• no/a few conflicts in GIT

Cons:

• not working well for big projects
• overwriting each other can happen until metadata is not merged to the master branch
• not clear what metadata version is on sandboxes when having multiple open Pull/Merge Requests

Branch per org – individual deployments

Pros:

• Somehow enables Continous Delivery/Deployment
• Clear what version of metadata is on which org
• Multiple teams can deliver code independently from each other

Cons:

• GIT conflicts may happen, especially when developers use different branches and commit to deliver same changes
• Developers have to have knowledge about how GIT is working (should be obvious and a must-have, but apparently it is not)
• non-prod branches can contain lost&forgotten changes
• Require keeping long-live branches (qas, staging, master) in shape, and looking after the correct order of merging Pull Requests

Branch per org – common deployments

Pros:

• Clear what version of metadata is on which org
• Release is taking all changes from qas, through staging up to the master, no changes are lost&forgotten
• Releases can be easily synchronized with X weeks sprints
• GIT conflicts occur rarely

Cons:

• a lot of effort is required to release
• requires a freeze period when new changes are not introduced in the qas branch until deployment to staging is successful
• common responsibility – due to one team’s changes making deployment failing, all teams are delayed

Branching Strategy Summary

Choose a branching strategy that suits your needs. There is no golden strategy, especially for Salesforce.
There will be always some for and against – just choose wisely what your company currently needs.
Remember that the branching strategy can be always changed as the team grows/shrinks or gets mature enough.

Examples:

• For small companies with a few developers I would choose either Single long live branch or Branch per org - individual deployments
• For big enterprises that have common, scheduled releases of multiple teams I guess the best option would be Branch per org - common deployments
• For an any-sized company that needs to have independent releases, the right option seems to be Branch per org - individual deployments

Okay I have chosen the branching strategy, what’s next?

Create a Salesforce CICD pipeline

Your pipeline should be designed according to your branching strategy and 99 other factors

Here is a sample pipeline that can be used for Salesforce.
Grey boxes below are options you can incorporate to streamline the process. Some options are mutually exclusive like Deployment – Full repo vs Git Diff

But the CICD pipeline is a very wide topic which deserves a separate blog post.

If you want to read more about different approaches towards deploying metadata for Salesforce – check this post

If you have some questions or want to add some pros/cons other branching strategy feel free to put that in the comment section below. 🙂
PS: There is no need to create an account for adding a comment – just click on the Name text field below and click the checkbox – Post as a guest

Was it helpful? Check out our other great posts here.