New branching strategy to improve working with multiple GoLives within the same project

Managing parallel releases can be one of the trickiest challenges in software development. Traditional branching strategies, such as GitFlow or GitHub Flow, often assume a linear journey toward production: one mainline branch, one release at a time.

But real-world projects are rarely this simple. Many organizations need to prepare multiple GoLives in parallel, sometimes for different customers, sometimes for different environments, and sometimes for staggered rollouts of the same product. Without the right strategy, this can lead to confusion, conflicts, and rushed hotfixes.

To address this challenge, I’ve together with a colleague designed a branching strategy that allows teams to work on multiple GoLives simultaneously, while keeping the development branch isolated as a true sandbox environment.

Why versioning matters

Versioning is more than just tagging a release number. It’s the backbone of a predictable and stable delivery process.

• Confidence in environments: When every branch corresponds to a release or pre-production state, teams know exactly what is deployed and where.

• Isolation of work: Developers can be confident their features or hotfixes are scoped to the correct release cycle.

• Reduced risk: Each GoLive is versioned and tested independently, which prevents changes from leaking into the wrong environment.

By tying features and hotfixes directly to release and pre-production branches, versioning becomes not just a technical necessity but a central tool for project coordination.

What’s new

This approach introduces two important changes compared to traditional branching strategies:

1. Release/Preprod as Anchors for New Work

   • Feature branches and hotfixes are not created from dev or main.

   • Instead, they branch directly from the release or preprod version they belong to.

   • This ensures that every change is tied explicitly to the GoLive it is meant for.

2. DEV as a Pure Sandbox

   • The dev branch is no longer part of the release pipeline.

   • It exists solely for developer testing, experimentation, or prototyping.

   • Nothing merges back from dev into release branches, which prevents instability from creeping into production.

The result? Teams can work on multiple GoLives in parallel, finalizing one release for pre-production while already developing features for the next.

Where and how to apply this strategy

This branching strategy is especially valuable in projects where:

• Multiple releases are planned to go live at different times.

• Testing requires both a dedicated test environment and a pre-production environment that mirrors production.

• Hotfixes need to be scoped to specific GoLives without disrupting other versions.

How it works in practice:

1. A release branch (e.g., release/1.0.0) is created for an upcoming GoLive.

2. Developers create feature branches (e.g., feature/1.0.0/feature-name) directly from that release branch.

3. When a release is ready, it is promoted to pre-production (preprod/1.0.0) for validation.

4. Once verified, it is merged into main (production).

5. Meanwhile, a new release branch (e.g., release/2.0.0) can already be in progress, enabling two GoLives to be prepared in parallel.

6. Hotfixes are branched directly from pre-production, ensuring that fixes apply only where needed.

This structure creates a clear separation of responsibilities: release branches for development, preprod branches for stabilization, and main for production.

Why I recommend this

I find this strategy valuable because it solves several pain points that traditional models often leave unresolved:

• Clarity: Everyone knows which GoLive a feature or fix belongs to.

• Parallelism: Multiple GoLives can be worked on simultaneously without overlap or confusion.

• Cleaner development process: DEV becomes what it was always meant to be—a sandbox—without the burden of release preparation.

• Reduced release risk: Hotfixes and features are scoped precisely to the versions that matter, reducing the chance of introducing unintended changes.

In short, this model embraces the complexity of real-world delivery schedules instead of forcing everything into a single linear flow. It provides structure without rigidity, and flexibility without chaos.