If you are interested in trying Gitflow in Pipelines, please reach out to our team via our in-app chat so we can provide the necessary support.
Pipelines currently supports two branching models: the Gearset Gitflow branching model and the Gearset expanded branching model. This article focuses on the Gitflow branching model.
Unlike the expanded branching model, Gitflow does not use long-lived environment branches for each static environment in your pipeline. Instead, all work flows through a shared integration branch, often called develop, and temporary branches are created for features and releases before the release is merged into main.
Introduction
Gitflow in Gearset Pipelines brings a first-class, native Gitflow experience to Salesforce teams. It allows teams to group features early, validate them together, and move a release as a single unit through downstream environments. This branching strategy is familiar to many enterprise engineering teams and is now supported in Pipelines with the same reliability, automation and governance already provided by the expanded branching model.
Features
Gitflow in Pipelines includes a number of features designed to support the model's workflow. Some features are familiar to Pipelines teams today, such as in-app merging, tight source control integration and issue tracking support (Jira and Azure DevOps), while others are tailored specifically to Gitflow:
Visualization: Pipelines provides a purpose-built visualization for Gitflow, showing each phase of the workflow in clearly separated sections: development, release validation and testing, and deployment to production. This makes it easy for teams to understand the current state of the release and where attention is needed.
Team Collaboration: Gitflow promotes close collaboration by having all contributors work from the same shared base branch. This gives every team member visibility into the latest state of development when starting new work. Building on top of in-flight changes, rather than waiting for those changes to reach production, helps teams maintain momentum, reduce integration risks, and surface issues early.
Release Management: When all changes for an upcoming release are ready, release managers can create a release branch with a single click. Pipelines automatically consolidates the relevant features, changes and tickets into a cohesive release, which can then be deployed together to testing environments. This provides structure and visibility from the start of the release process, improves predictability across environments and reduces the coordination overhead typically required to manage many independent changes.
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 ongoing development.
Below is the current implementation of the Gitflow branching model in Pipelines (this model will expand and mature over the coming months):
The diagram above represents one example of how this branching model can be used. Your team determines which Salesforce orgs map to which branches. For example:
developmay deploy to an Integration, SIT, or QA orgRelease branches may deploy to UAT or Staging for final validation before merging into
mainand deploying to production
Gearset Gitflow Pipelines support one Integration environment, zero or one Release & Testing environment, and one Production environment. Gitflow includes stages where multiple features are merged into the same branch and are expected to move forward together.
How It Works
Users create feature branches from
developwhen beginning work on new changes. This ensures they are working from the most up-to-date version of ongoing development.Once the work is complete and validated, the feature branch is merged back into
developand deployed to the respective org(s). All integration happens here, allowing teams to surface conflicts and resolve any issues early.Once all the features for the next release are present in the integration branch, a release branch is created from
developfor final validation and testing against any org(s). This branch typically contains all work currently merged into develop as Gitflow is not designed to let you selectively choose PRs for the release.Once ready, a PR for the release branch is opened against
mainfor any final checks, after which it can be merged and deployed to production.