--- title: "Top 3 Git Branching strategies for Salesforce" url: "https://blog.beyondthecloud.dev/blog/git-branching-strategies-for-salesforce" author: "Maciej Ptak" published: "2022-12-03" updated: "2023-10-14" tags: "git branching strategy for multiple environments, git release branching strategy, salesforce branching strategy, salesforce devops, salesforce git" --- # Top 3 Git Branching strategies for Salesforce By [Maciej Ptak](https://blog.beyondthecloud.dev/author/maciej-ptak.md), December 3, 2022 Hello there! ![Salesforce Git Branching Strategy](https://wordpress.beyondthecloud.dev/wp-content/uploads/2022/12/branching-strategy-post-linked-in.png) ## 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? ![Dropbox FTW](https://wordpress.beyondthecloud.dev/wp-content/uploads/2022/11/dropbox-the-new-git-1024x480.webp) 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: ![Branch flow description](https://wordpress.beyondthecloud.dev/wp-content/uploads/2022/12/branching-description.png) ### Single long-live branch ![single long live branch](https://wordpress.beyondthecloud.dev/wp-content/uploads/2022/12/single-long-live-branch.png) 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 ![branch per org - individual strategy - git strategy for salesforce](https://wordpress.beyondthecloud.dev/wp-content/uploads/2022/12/branch-per-org-individual-deploy.png) 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 ![branch per org - common deployments - git strategy for salesforce](https://wordpress.beyondthecloud.dev/wp-content/uploads/2022/12/branch-per-org-common-deploys.png) 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` ![Salesforce sample pipeline](https://wordpress.beyondthecloud.dev/wp-content/uploads/2022/11/salesforce-pipeline.png) 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](https://beyondthecloud.dev/blog/how-to-deploy-in-salesforce) --- 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](https://beyondthecloud.dev/blog).