This article explains how the Gitflow branching strategy works in Pipelines and how it maps to your Salesforce environments. If you are still deciding whether Gitflow is the right fit for your team, start with this article before continuing.
The Branching Model
Gitflow is built around two long-lived branches:
main(or your respective production branch) contains production-ready code.develop(or your respective integration branch) is the primary integration point for all ongoing work. It represents the latest state of everything your team is building for the next production release.
All other branches in Gitflow are short-lived and serve a specific purpose within the release cycle. The branching model can be seen below:
Feature Branches
At this stage, the team is building and integrating changes for the next release.
A developer creates a feature branch from
develop, ensuring they are always working from the most up-to-date version of the team's ongoing work.Once the work is complete and has passed reviews, the feature branch is merged back into
develop.This is where all active work comes together, allowing the team to surface and resolve conflicts early while the flexibility to fix them still exists.
Release Branches
Once the team is ready to release, a release branch is cut to lock scope and validate the full body of work.
Once all the features for the next release are present in
develop, a release branch is cut and the release scope is locked.The release branch contains everything currently in
developand moves forward as a single unit through any release-level testing environments.Once testing and/or sign-off are complete, a PR is opened from the release branch against
mainfor any final checks.Once merged to
main, the release is deployed to production.
Not every release follows the happy path. The following options exist to handle issues and urgent fixes that arise outside the normal flow:
Bug Fix Branches (Not Visualised)
If an issue is identified after a release branch has been cut, a bug fix branch is used to resolve it without disrupting new work in develop.
A "bug fix" feature branch branch is created directly from the release branch.
Once the fix is complete and has passed reviews, it is merged back into the release branch.
The fix is then propagated back to
developto keep all branches aligned.
Hotfix Branches
For urgent fixes required after a release has been shipped to production, a hotfix branch allows changes to be made directly against production.
A hotfix branch is created directly from
mainfollowing a production deployment.Once the fix is complete, it is merged back into
main.The fix is then propagated back to
developand any open release branches to keep all branches aligned.
Environments
In Pipelines, the Gitflow branching structure maps to your environments across three distinct stages. Your team determines which environments map to which stages based on your desired delivery process.
Integration (Required)
This stage maps to your develop branch and is where all individual feature work is integrated. One environment is currently supported at this stage.
Use this environment for integration testing as features are merged into
developone by one.Because the release is not yet locked at this stage, this is the right place to catch and fix individual issues.
Release & Testing (Optional)
This stage maps to the release branch and is where the consolidated release is tested before production. One environment is currently supported at this stage.
Unlike the expanded branching model, Gitflow does not use long-lived environment branches in this stage. The release branch is short-lived by design, which reduces branch overhead and ensures there is no ambiguity about what is being tested or deployed at any point.
Use this environment for release-level testing where the entire release is tested together as a complete package.
Because the release is locked at this point, testing here should focus on validating the full body of work rather than individual features.
Issues identified here should be fixed forward on the release branch before it proceeds to production.
Production (Required)
This stage maps to main and is the final deployment step.
By the time the release reaches this stage, it has already been assembled, tested, and validated as a complete unit.
This is a final check to confirm the release branch can be safely merged into
mainand deployed to production.
Now that you understand how Gitflow works in Pipelines and how it maps to your environments, you are ready to set up your pipeline.
Feedback
Need more environments than the current setup supports? We are working to expand environment support in future updates. In the meantime, get in touch with us and we will work with you to find the best path forward.