Pipelines supports two branching strategies: the expanded branching model (feature independence) and Gitflow. Both are valid approaches to delivering Salesforce changes, but they reflect fundamentally different ways of planning, building, and releasing work. Choosing the right one for your team matters as it shapes how your developers collaborate, how releases are formed, and how much coordination overhead your release managers carry.
This document explains how Gitflow works, what it is built for and the tradeoffs it involves, so you can decide whether it is the right fit for your team.
How does Gitflow work?
Think of your release process like filling and shipping a container.
Throughout a sprint, your developers complete individual pieces of work, features, enhancements, or bug fixes. Think of each one as a parcel, representing a feature branch. As each parcel is finished and reviewed, it gets loaded into a shared shipping container. That container is your develop branch, the single place where all in-flight work comes together. Parcels loaded into the container stay there until the rest of the sprint's work is ready.
When your team is ready to release, the container is sealed. That moment is when a release branch is cut from develop, locking in exactly what will ship. From here, the sealed container moves through your later environments as a single consolidated unit. Testing happens at the container level, not the parcel level. If something inside needs fixing, you must fix it before the container moves on.
Once the release has passed all quality checks and sign-off, it ships to production. main reflects the new production state, and the cycle begins again.
Here is how that translates into the Gitflow branching strategy:
The result is a release process built around one well-defined unit of work, rather than a shifting collection of independent changes scattered throughout the pipeline.
Who is Gitflow for?
The following characteristics are strong signals that Gitflow is the right fit.
You want to ship changes together on a defined cadence
Your team wants to bundle work into a single release and ship it to production on a predictable schedule, whether weekly, monthly, or aligned to your sprint cadences. Releases are planned events, not continuous or ad hoc deployments.
You want certainty over what will ship
Your team wants to know from the start of a sprint what is going to production and when. Work that is merged into develop is understood to be production-bound. Planning is rigorous enough that scope changes after that point are the exception, not the norm. If your team frequently needs to hold back or remove features late in the process, Gitflow is likely not the right fit.
You want your team building on top of each other's changes
Your developers regularly work on changes that interact with or depend on what teammates are building. In Gitflow, everyone branches from and merges back into develop, so the team is always working from the latest shared state. Integration issues surface early, when they are cheaper to fix, rather than late in the release cycle when they are disruptive. Because work is continuously integrated into develop throughout the sprint, the release is being assembled from the start rather than constructed at the last minute.
You want to assemble and test your release as a single unit
Individual features are reviewed and validated before they merge into develop. However, once the release is cut, that single bundle of work is what moves through every subsequent environment. Everything that reaches release-level testing environments and production is the same package, so your team always knows exactly what is being tested, what will ship, and when. The risk of drift between environments is reduced by design.
You want to reduce production risk
Because the full release has been tested as a complete unit before it reaches production, there are no late-stage surprises about what is in it or how the changes interact with each other. Production becomes a controlled deployment of something your team already understands and has validated completely, reducing the likelihood of failures and emergency fixes after go-live.
You want to reduce coordination overhead as you scale
As team size and the number of changes grow, managing many independent features through a pipeline creates compounding overhead. Repeated promotions, recurring conflict resolution, and the effort of tracking what is where across environments quickly accumulate. In Gitflow, individual contributors promote a unit of work once. Once that feature is merged into develop, their involvement in moving that work forward effectively ends and they can focus on their next task. Once a release is created, the release manager coordinates a single unit of work rather than dozens of independently moving parts.
What are the benefits and tradeoffs?
Choosing Gitflow over feature independence means making a deliberate set of decisions and tradeoffs about how your team works. Understanding what you are committing to is as important as understanding what you gain.
How you build changes
Gitflow means your team always branches from and builds on the latest shared state of develop, so integration issues surface early when they are cheaper to fix. However, a problem introduced in develop affects everyone working from it, which is why a strong review process at the point of merging is essential. The alternative with feature independence is branching from a production baseline, which keeps changes fully isolated during development. That isolation comes at a cost: your team cannot build on each other's in-flight work, and integration risk accumulates silently until changes are combined later in the process when it is more expensive to fix.
When you commit to shipping to production
Gitflow gives your team clarity and predictability over what will ship and when by locking release scope early. That requires accepting that once work is merged into develop, it is production-bound. If your team regularly receives late scope changes from the business, or regularly needs the flexibility to hold back or remove features close to a release date, feature independence gives you that control. However, this means it will not be clear until closer to the release date exactly what is ready and what will ship, which can create uncertainty for the business, release managers and/or testers who need to plan around a known scope.
How you test changes
Gitflow means the entire release moves through testing environments as a single consolidated unit, with fewer promotions, conflicts already resolved, and significantly reduced risk of environment drift. That requires accepting that features cannot move independently through testing. The alternative with feature independence is moving and testing features individually at each environment, which preserves that flexibility, but means repeated promotions, recurring conflict resolution for the same changes, and a higher operational burden as the number of in-flight features grows.
How your production release looks
Gitflow means that by the time a release reaches production, it has already been assembled, tested, and validated as a complete unit. Production is a controlled deployment of something your team fully understands. The alternative with feature independence is assembling the release later by selecting individual features closer to the production date. If combining those changes causes unexpected issues at that point, the release may need to be reconstructed and testing re-done when it is most disruptive to do so. The release may also no longer reflect what was tested in earlier environments, increasing the risk of late-stage issues.
Is Gitflow right for your team?
If the characteristics above resonate and the tradeoffs are ones your team can successfully work within, Gitflow is likely the right fit. The next step is understanding how Gitflow works in Pipelines.