DEV Community: Vinicius de Santana

Git Fluid Flow: A Branching Strategy for Decoupled Task Promotion

Vinicius de Santana — Thu, 18 Jun 2026 17:31:14 +0000

Introduction

Consider the following scenario:

Feature A is ready for production.
Feature B still contains bugs identified by QA.
Feature C is waiting for client approval in staging.

Despite that, all of them belong to the same promotion cycle between environments. As a result, Feature A, which has already been developed, tested, and approved, ends up waiting for the others before it can be delivered.

If you work in medium-sized or large teams, you've probably experienced something similar.

As organizations grow, delivery workflows tend to become increasingly unpredictable. Different teams work on different features, approvals happen at different speeds, and priorities constantly change. While some changes need to reach production quickly, others may remain under validation for weeks or wait for business decisions before moving forward.

In this context, a simple question emerges:

Why should an independent task depend on the lifecycle of other tasks in order to be promoted?

Modern branching strategies have solved many important problems over the years. They helped organize teams, reduce risks, and structure integration and deployment processes. However, in environments with a high volume of changes and continuous deployment, it is still common to find workflows where environments represent mandatory promotion stages, causing independent tasks to share the same journey.

The result is familiar: blocked deliveries, process exceptions, emergency hotfixes, and an increasing need for parallel mechanisms to bypass limitations imposed by the workflow itself.

Fluid Flow emerged from observing this scenario.

Instead of treating environments as mandatory stages in a promotion pipeline, Fluid Flow proposes an approach based on decoupled task promotion, where each task has its own lifecycle and can be promoted independently to whichever product states make sense for that delivery.

The goal of this strategy is not to replace established models nor to serve as a universal solution for every context. Its purpose is to offer an alternative for teams dealing with multiple simultaneous deliveries, independent approval cycles, and the need to maintain reproducible software states without creating artificial dependencies between unrelated tasks.

Limitations of Git Flow and GitLab Flow in Modern Environments

Before introducing a new branching strategy, it is important to recognize one fact: Git Flow and GitLab Flow solved real problems and remain excellent choices for many contexts.

Git Flow brought structure to teams working with clearly defined release cycles. The model establishes a clear separation between development, release preparation, and emergency fixes, creating a predictable process for software evolution.

Later, GitLab Flow simplified many aspects of this approach. Instead of relying on multiple specialized branches for releases and hotfixes, the model aligns more closely with the operational reality of many modern teams, especially those practicing continuous integration and frequent deployments.

However, both models share an important characteristic: change promotion remains strongly tied to environment progression.

Consider a simplified structure:

Simplified Git structure (screenshot by author)

In this scenario, environments represent a natural progression of the software. What is in staging has usually already passed testing. What is in production has usually already passed staging.

This approach works very well when deliveries move forward together.

But what happens when they do not?

Imagine three independent features: Social Login, PDF Export, and ERP Integration.

Social Login is ready for production.
PDF Export still contains issues identified by QA.
ERP Integration is waiting for approval from an external department.

Although these features have completely different lifecycles, they often end up sharing the same promotion flow. As a consequence, a ready-to-ship task may remain blocked waiting for unrelated work to advance.

In small teams, this impact is usually limited. However, as the number of developers, stakeholders, and concurrent deliveries increases, this dependency becomes increasingly noticeable.

Both Git Flow and GitLab Flow were conceived around the assumption that software states evolve in a relatively linear fashion. In many contexts, this assumption remains valid and desirable.

However, some organizations operate differently. Different features may need to move at different speeds, reach different environments, and be promoted at completely independent moments.

When that happens, a different need emerges: decoupling task promotion without sacrificing traceability, reproducibility, or control over product states.

This is precisely where Fluid Flow begins.

What is Fluid Flow?

Fluid Flow is a branching strategy for decoupled task promotion.

The idea starts from a simple premise:

Independent tasks should be able to evolve independently.

Although this statement sounds obvious, many branching strategies associate feature promotion with the promotion of the environments through which those features travel. As a result, unrelated tasks end up sharing the same lifecycle even when they have completely different levels of maturity, priorities, and approval processes.

Fluid Flow reverses this logic.

Instead of using environments as the primary mechanism for software evolution, the strategy places the task at the center of the promotion process.

This means that every delivery has its own lifecycle and can move independently from other tasks, as long as it is ready to reach the desired product state.

In other words:

The unit of promotion is no longer the environment. It becomes the task.

This shift in perspective produces an important consequence.

In traditional models, environments usually represent stages in a temporal progression:

testing
 ↓
staging
 ↓
main (production)

In Fluid Flow, product states no longer represent a mandatory promotion sequence. Instead, they become reproducible and independent states of the product.

This enables scenarios where different tasks coexist in different states without blocking each other's evolution.

For example, one feature may exist only in testing while another is already running in production. Likewise, a critical fix may be promoted directly into production without depending on unrelated tasks still undergoing validation.

The result is a more flexible workflow for teams handling multiple simultaneous deliveries whose approval cycles do not necessarily follow a single chronological path.

The name Fluid Flow comes precisely from this characteristic.

Instead of imposing a rigid trajectory for every delivery, the strategy allows each task to follow its own path toward the product states for which it was intended, respecting both operational and business needs.

This flexibility, however, does not imply a lack of structure. To ensure that decoupled deliveries remain traceable, reproducible, and understandable over time, Fluid Flow establishes a small set of fundamental concepts that serve as the foundation of the strategy.

Fundamental Concepts

Fluid Flow was designed to be simple to understand and flexible enough to adapt to different organizational contexts.

For this reason, the strategy relies on only a few fundamental concepts.

State Branch

A State Branch represents a durable and reproducible state of the product.

The meaning of that state depends on the organization's needs.

In some teams, a State Branch may represent an environment:

env/testing
env/staging
main

In others, it may represent software versions:

v1
v2
v3

Or even specific releases:

release/2026.1
release/2026.2

Fluid Flow does not impose a specific organizational structure. Its only requirement is that these branches represent stable product states capable of serving as starting points for new work.

For this reason, every task must originate from a State Branch.

Task Branch

A Task Branch represents an independent unit of delivery.

It should have a clear scope, identifiable value, and the ability to be promoted without depending on the simultaneous delivery of unrelated functionality.

In practice, a Task Branch is very close to the concept of a User Story used by many agile teams:

A task should be independent, valuable, small, testable, and capable of being delivered in isolation.

Examples:

task/social-login
task/pdf-export
task/erp-integration

or:

feat/social-login
fix/token-fix
patch/report-error

The strategy does not impose a specific naming convention. What matters is that the branch represents a single delivery with its own lifecycle.

While a State Branch represents a product state, a Task Branch represents a change to that state.

Independent Promotion

Independent Promotion is the central concept of Fluid Flow.

In traditional models, promotion typically happens through environment progression. A change advances because the environment advances.

Fluid Flow works the other way around: A change advances because the task advances.

This means the same task can be promoted into different State Branches according to its maturity and operational needs.

For example, consider a task task/login-social created from a commit on main:

Task branch has independent promotion (screenshot by autor)

Likewise, different tasks can coexist in different product states:

Different tasks can coexist in different product states (screenshot by author)

Without any mandatory dependency between them.

This characteristic allows independent features to follow different validation and approval cycles, reducing artificial bottlenecks between deliveries.

In summary:

In Fluid Flow, the unit of promotion is the task, not the environment.

The Fluid Flow Axioms

The concepts introduced so far define the elements of the strategy. The axioms define how those elements are expected to behave.

Unlike operational rules or team-specific conventions, the axioms represent the fundamental principles that characterize Fluid Flow. They preserve the identity of the strategy regardless of the tooling, organizational structure, or delivery process being used.

Axiom 1: The Task Is the Fundamental Unit of Promotion

In Fluid Flow, promotion does not happen because an environment evolves.

Promotion happens because a task evolves.

Each task has its own lifecycle and its own journey through the delivery process.

This is the primary shift in perspective proposed by the strategy.

The unit of promotion is the task, not the environment.

Axiom 2: Independent Tasks Must Be Able to Evolve Independently

A task should not depend on the promotion of other tasks in order to advance through its own lifecycle.

If a feature is ready to reach a particular product state, its promotion should not be artificially blocked by unrelated deliveries.

For example:

task/social-login

may be promoted to production.

While:

task/pdf-export

remains in staging.

And:

task/erp-integration

continues in testing.

Each delivery evolves according to its own level of maturity and business requirements.

Axiom 3: State Branches Represent Reproducible Product States

State Branches represent known and reproducible states of the software.

These states may have different meanings depending on the organization's context:

Environments.
Versions.
Releases.
Customer-specific customizations.
Independent product evolution lines.

What matters is not the naming convention, but the ability to represent a consistent and understandable state of the system.

Axiom 4: The Workflow Must Remain Decoupled from Organizational Structure

Fluid Flow does not require specific environments, naming conventions, merge strategies, or versioning policies.

The strategy was designed to adapt to the organization's needs rather than imposing a single operational model.

As a result, different teams can use the same approach while maintaining completely different environments, validation processes, and delivery cycles.

Flexibility Without Losing Control

The axioms do not dictate:

How merges should be performed.
When rebasing should be used.
How conflicts should be resolved.
How branches should be named.
How pipelines should be built.
How environments should be organized.

These decisions remain the responsibility of the team.

The role of the axioms is to establish the minimum set of principles required to preserve the strategy's defining characteristic:

Independent tasks should be able to evolve independently.

Practical Example

So far, we have explored the concepts and axioms that define Fluid Flow. Now let's see the strategy in action through a common scenario faced by teams practicing continuous delivery.

Consider an application with three product states represented by the following State Branches:

env/testing
env/staging
main

Where:

env/testing represents the testing environment.
env/staging represents the staging environment.
main represents the production environment.

At a certain point, three new requests arrive:

task/social-login
task/pdf-export
task/erp-integration

Each task represents an independent delivery with its own scope, acceptance criteria, and validation process.

The tasks are created and developed normally.

main
 ├─ task/social-login
 ├─ task/pdf-export
 └─ task/erp-integration

After development is completed, all tasks are promoted to the testing environment.

task/social-login    -> env/testing
task/pdf-export      -> env/testing
task/erp-integration -> env/testing

During validation, the QA team identifies issues in the PDF Export functionality.

At the same time:

Social Login is approved.
ERP Integration remains under testing.
PDF Export returns to development for fixes.

At this point, Social Login is promoted to staging.

task/social-login -> env/staging

Meanwhile:

task/pdf-export continues receiving fixes.
task/erp-integration remains under validation.

After functional approval in staging, Social Login is promoted to production.

task/social-login -> main

Notice that no other task needed to reach the same stage for this to happen.

task/pdf-export remains in testing.
task/erp-integration continues its normal validation process.

Later, ERP Integration is promoted to staging.

task/erp-integration -> env/staging

At the end of this scenario, we have something similar to:

social-login
 └─ main

erp-integration
 └─ env/staging

pdf-export
 └─ env/testing

Each task exists in a different product state.

Each task has a different level of maturity.

Each task evolves at its own pace.

Yet none of them blocks the promotion of the others.

This is the primary objective of Fluid Flow.

In traditional models, promotion typically follows environment progression. When a group of changes moves forward, every change contained within that state moves forward as well.

Fluid Flow works differently.

Tasks advance individually as they satisfy the requirements necessary to reach each product state.

The result is a workflow where independent deliveries remain independent throughout their entire lifecycle.

A task should be promoted when it is ready, without waiting for other tasks to become ready.

Benefits

Every branching strategy involves trade-offs.

The goal of Fluid Flow is not to eliminate the inherent complexity of software development, but rather to reduce some of the most common sources of friction faced by teams managing multiple simultaneous tasks with independent validation and approval cycles.

When applied in the right context, the model provides several important benefits.

Decoupled Task Promotion

The primary benefit of Fluid Flow is allowing independent tasks to remain independent throughout their entire lifecycle.

In many traditional models, different features end up sharing the same promotion path between environments. As a result, a task that is ready to ship may be forced to wait for other tasks that have not yet reached the same level of maturity.

In Fluid Flow, each task follows its own path.

This allows features to advance according to their own validation criteria, approval processes, and business priorities.

A task should be promoted when it is ready, without waiting for other tasks to become ready.

Reduced Team-Level Bottlenecks

In larger organizations, multiple teams often work on the same product simultaneously.

Not every task has the same priority.

Not every task carries the same level of risk.

Not every task follows the same approval process.

By making the task the fundamental unit of promotion, Fluid Flow reduces the need for artificial coordination between unrelated work items.

The result is fewer bottlenecks caused solely by the structure of the branching workflow.

Reproducible Product States

In Fluid Flow, State Branches represent known software states.

These states may represent environments, versions, releases, or any other product evolution line adopted by the organization.

This approach makes it easier to understand what composes a particular product state at any given moment and simplifies the creation of new work from known references.

It also makes it easier to reproduce specific scenarios for testing, maintenance, and bug fixes.

Flexibility Across Delivery Models

Not every organization operates the same way.

Some practice continuous deployment.

Others maintain multiple product versions simultaneously.

Some support customer-specific customizations.

Others rely on formal release cycles.

Fluid Flow does not require a specific organizational structure to work.

The same strategy can be applied using environments, versions, releases, or other mechanisms for representing product states.

This flexibility allows teams to adapt the model to different contexts without changing its fundamental principles.

Simpler Automation and Pipelines

When promotion no longer depends on the collective evolution of environments, pipelines tend to become more predictable.

Instead of interpreting complex release stages, automation can focus on simpler and more objective events:

A task was promoted to a specific State Branch.
A State Branch received new changes.
A specific product state needs to be deployed.

This approach simplifies the construction of continuous integration and continuous delivery pipelines, reducing special rules and operational exceptions.

Less Reliance on Parallel Processes

A common situation in teams practicing frequent deployments is the creation of parallel mechanisms to bypass limitations of the main workflow.

Emergency hotfixes.

Temporary branches.

Manual promotions.

Special release procedures for specific features.

Although these mechanisms may still be necessary in some situations, decoupled task promotion reduces how often they are needed simply to prevent one task from being blocked by another.

Better Alignment with Operational Reality

Perhaps the greatest benefit of Fluid Flow is how closely it reflects the way many organizations already operate.

In teams handling multiple simultaneous deliveries, multiple business areas, numerous stakeholders, and constantly shifting priorities, features rarely evolve at the same pace.

Fluid Flow acknowledges this reality and turns it into a natural part of the strategy.

Instead of artificially synchronizing all work, the model allows each task to follow its own lifecycle while preserving traceability, control, and predictability throughout the delivery process.

Operational Recommendations

The recommendations presented in this section are not mandatory requirements for adopting Fluid Flow. They represent practices that tend to maximize the benefits of the strategy while minimizing operational issues commonly encountered during its adoption.

Prefer Creating Tasks from Their Target State Branch

Whenever possible, create a task from the State Branch that represents its final destination.

For example:

main
 └─ task/social-login

instead of:

env/testing
 └─ task/social-login

When a task is created from an intermediate State Branch, it may inherit changes that have not yet reached their final intended state.

This increases the risk of unintended dependencies between features that should remain independent.

Creating tasks from their target State Branch helps preserve decoupling and simplifies future promotions.

Keep Tasks Small and Independent

Fluid Flow works best when each task represents a clear and self-contained delivery.

In practice, this means a task should have:

A specific objective.
A limited scope.
Well-defined acceptance criteria.
The ability to be delivered independently.

The larger the task, the greater the likelihood of dependencies, conflicts, and promotion bottlenecks.

Be Careful with Task Dependencies

Independent promotion is most effective when tasks are also independent from both a technical and functional perspective.

For example:

task/login
task/permissions

If the permissions implementation depends directly on the existence of the login functionality, both tasks may belong to the same evolutionary path and should be planned accordingly.

The lower the coupling between tasks, the greater the flexibility during promotion.

Use State Branches with a Clear Purpose

State Branches should have a clear meaning understood by the entire team.

For example:

env/testing
env/staging
main

or:

v1
v2

or:

release/2026.1
release/2026.2

What matters is that every team member can quickly understand the role of that branch within the workflow.

Ambiguous State Branches reduce traceability and make it harder to understand the actual state of the product.

Remove Completed Task Branches

Once a task has fulfilled its purpose, its Task Branch typically loses operational value.

Keeping old branches indefinitely tends to increase repository complexity and make navigation more difficult over time.

Whenever possible, remove branches that have completed their lifecycle.

If additional changes are required in the future, a new task can be created from the appropriate State Branch.

Automate Promotion Whenever Possible

Fluid Flow does not require a specific CI/CD implementation.

However, the strategy tends to produce better results when validation, build, and deployment processes are automated.

Because promotions occur independently, automated pipelines help ensure predictability and reduce the operational cost of managing multiple concurrent tasks.

Automation also improves traceability throughout the lifecycle of each task.

Adapt the Strategy to Your Reality

Fluid Flow was not designed to impose a single way of working.

Different teams have different needs.

Some organizations rely on validation environments.

Others maintain multiple product versions.

Some practice continuous deployment.

Others operate through planned release cycles.

The purpose of the strategy is not to replace these particularities, but to provide a model that enables independent tasks to be promoted independently without creating artificial dependencies between them.

For that reason, adapt these recommendations whenever necessary while preserving the fundamental axioms that define Fluid Flow.

Conclusion

Branching strategies exist to help teams deliver software with safety, predictability, and traceability. However, as products and organizations grow, the challenges faced by teams evolve as well.

In many modern environments, the problem is no longer limited to organizing source code or managing versions. The challenge becomes enabling multiple tasks to coexist, be validated at different speeds, and reach their desired product states without creating artificial dependencies between one another.

Fluid Flow emerged from this need.

Throughout this article, we explored a proposal built around a simple idea: the task is the fundamental unit of promotion.

This shift in perspective moves the focus away from environments and toward the work itself. Instead of depending on the collective evolution of product states, each task gains its own lifecycle and promotion path.

This approach allows independent features to evolve independently, reducing operational bottlenecks and providing greater flexibility for teams handling multiple simultaneous tasks.

Naturally, this flexibility comes with trade-offs. Fluid Flow does not eliminate the need for sound engineering practices, does not solve existing technical dependencies, and does not replace proper quality, automation, or governance processes. Like any branching strategy, it represents a set of choices and compromises.

For that reason, the goal of this article is not to present a universal solution nor to suggest that established models should be abandoned. Git Flow, GitLab Flow, Trunk-Based Development, and other strategies remain excellent options when applied to the contexts for which they were designed.

Fluid Flow is simply an alternative for a specific problem: Environments where independent tasks need to evolve independently.

Instead of treating environments as mandatory stages in a promotion pipeline, Fluid Flow treats them as reproducible product states.

And when that shift in perspective makes sense for an organization, a natural consequence emerges:

A task should be promoted when it is ready, without waiting for other tasks to become ready.

Choosing the ideal Git branching strategy for your project

Vinicius de Santana — Mon, 01 Jun 2026 14:04:03 +0000

The Git is the standard version control system in modern software development. With the ability to track changes and facilitate collaboration between teams, Git allows different versions of the source code to coexist, enabling parallel work and code maintenance.

Branching strategies are roadmaps teams use to organize their work, maintain control of different code versions, and collaborate smoothly. They define how developers should create, use, and integrate branches throughout the software development lifecycle. Without a clear strategy, teams may face challenges such as frequent merge conflicts, difficulty tracking progress, and instability in the main codebase. Git is a flexible tool and allows different forms of collaboration, there is no single solution for every scenario and teams need to choose the branching strategy that best adapts to their needs.

Exploring the Main Git Branching Strategies

Branching strategies evolved to support different development scenarios. Understanding the nuances between them is the first step toward making an informed choice.

Trunk-Based Development (TBD)

In Trunk-Based Development, developers integrate small updates into a main branch, known as the trunk or main. This strategy emphasizes rapid integration with a minimal number of branches, promoting faster iteration.

Trunk-Based Development For Smaller Teams (trunkbaseddevelopment.com)

In TBD, developers work directly on the main branch or use short-lived branches, with a lifecycle of a few hours or at most one day, resisting any pressure to create other long-lived development branches. Code integration and testing happen continuously and pull requests are used for code review before merging feature branches into the trunk. A common technique in TBD is the use of "feature flags" to isolate features that are not yet complete, allowing the code to be integrated without affecting the end-user experience.

Scaled Trunk-Based Development (trunkbaseddevelopment.comq)

TBD promotes rapid integration and continuous feedback, minimizes merge conflicts, and encourages frequent communication between team members. It facilitates the implementation of Continuous Integration and Continuous Delivery (CI/CD) and reduces complexity by avoiding the proliferation of long-lived branches.

TBD also presents challenges. It requires automated testing to guarantee the stability of the main branch. Attention to the process is essential to avoid problems. If not managed correctly, TBD can still lead to conflicts. In addition, the strategy requires developers to divide their work into small batches, which can be a significant change for some teams. The implementation of TBD can also be challenging in scenarios where maintaining multiple versions of the software is necessary.

Large technology companies such as the Google and the Facebook adopted TBD. Adoption by these organizations demonstrates its scalability and effectiveness for complex projects, as long as there is investment in automation and a well-established culture of collaboration. The ability to continuously integrate and reduce conflicts, even in large-scale projects, outweighs the challenges when supported by automation and rigorous code review practices.

Feature Branching

In the Feature Branching workflow, a new branch is created for each feature from the main branch. Developers work on this branch, making commits as necessary to register progress. Once the feature is complete, a pull request is created to request the integration of the changes back into the main branch. Other developers review the code in the pull request, providing feedback and ensuring quality. After review and approval, the feature branch is merged back into the main branch. Finally, the feature branch is usually deleted because it is no longer necessary.

How to publish your feature using feature branch workflow (atlassian.com)

Feature Branching offers several advantages. It provides clear isolation of changes for each feature, facilitating collaboration because multiple developers can work on different features simultaneously. If a feature introduces problems, its branch can be discarded without affecting the rest of the project. The strategy also facilitates code review and testing processes, resulting in a predictable development workflow.

However, Feature Branching also presents some disadvantages. There is a possibility of merge conflicts, especially if feature branches live for a long period. Managing and keeping many branches updated can become complex. There may be delays in merging changes into the main branch due to extensive reviews. In addition, if branches are not merged regularly, they can become stale, making future integration more difficult.

Feature Branching is a strategy that serves as the foundation for more complex models such as Gitflow and is also adapted into simpler workflows such as GitHub Flow and GitLab Flow. Its flexibility allows it to be used by teams of different sizes and project complexities.

Gitflow

The Gitflow is a structured branching strategy that uses multiple branches with specific purposes, including main, develop, feature, release, and hotfix. This strategy is suitable for projects with well-defined release cycles.

Gitflow workflow (atlassian.com)

In the Gitflow workflow, the main branch stores the official release history, reflecting a production-ready state. The develop branch serves as the integration branch for features under development. For each new feature, a feature branch is created from develop, and after completion it is merged back into develop. When a set of features is ready to be released, a release branch is created from develop to prepare the release by applying final adjustments and bug fixes. After the final tests, the release branch is merged into both main and develop, and the version in main is tagged with the release number. For urgent production fixes, a hotfix branch is created directly from main. After the fix, it is merged back into main (with a new version tag) and into develop (to guarantee that the fix is included in future releases). Branch naming conventions play a crucial role in this model.

Gitflow offers several advantages. It is well organized and provides a clear workflow for development, testing, and deployment. It is effective for projects with many contributors and supports large teams and complex projects. The isolation of releases guarantees stability during preparation, and the strategy facilitates parallel development.

However, Gitflow also presents disadvantages. It can be complex and slow for smaller projects or for teams seeking continuous delivery. Historically, it does not fully support CI/CD because of its longer development cycle. Gitflow requires strict adherence to the defined processes and may be considered overly prescriptive or inflexible by some teams. Although it was popular in the past, Gitflow has been losing space to lighter strategies such as GitHub Flow and Trunk-Based Development, especially for teams pursuing agility and CI/CD.

"(Git-flow) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. [...] To conclude, always remember that panaceas don't exist. Consider your own context. [...] Decide for yourself."

(Vincent Driessen, creator of GitFlow)

GitHub Flow

The GitHub Flow is a lighter branching strategy focused on continuous delivery, with only one main branch (main or master) and short-lived feature branches. This approach is suitable for small teams and web applications that do not require support for multiple production versions.

GitHub Flow Workflow (nhonvo.github.io)

In GitHub Flow, any code in the main branch should be ready to deploy. To work on something new, developers create descriptive branches from the main branch. Commits are made in these local branches and the work is regularly pushed to the remote branch with the same name. When feedback or help is needed, or when the work is considered ready for merge, a pull request is opened. After review and approval by another team member, the branch is merged back into the main branch. Once merged and pushed to main, deployment should happen immediately.

GitHub Flow offers ease of understanding. Its simplicity allows easy implementation of CI/CD. It is ideal for small teams and web applications and promotes faster releases and feedback cycles.

However, GitHub Flow has less structure for complex releases or for supporting multiple production versions.

The popularity of GitHub Flow lies in its simplicity and alignment with agile principles and continuous delivery, making it a preferred choice for modern teams. Its adoption by a leading platform such as GitHub reinforces its practicality and effectiveness.

GitLab Flow

The GitLab Flow is presented as a simpler alternative to Gitflow, combining feature-driven development and environment branches. It seeks a balance between the simplicity of GitHub Flow and the structure of Gitflow, offering more options to manage different environments and releases.

GitLab Flow

In GitLab Flow, development usually starts in the main branch. The strategy incorporates a pre-production branch to perform bug fixes before changes are merged back into main and deployed to production. Teams can add as many pre-production branches as necessary for their workflows, such as test, acceptance, and production. Commits flow from main to the pre-production branches and finally to the production branch, guaranteeing that each line of code is tested in all relevant environments. One of the distinctive characteristics of GitLab Flow is its integration with an issue tracking system, where every significant code change should be associated with an issue describing the purpose of the change.

GitLab Flow offers several advantages. It provides flexibility to collaborate and maintain multiple software versions across different environments. The strategy reduces the overhead associated with releases, tagging, and merges, which can be challenging in other workflows. It is particularly useful for teams that want to maintain a staging environment separated from production. GitLab Flow is built with DevOps practices in mind, facilitating integration with CI/CD pipelines.

Although it offers more flexibility than GitHub Flow, GitLab Flow can become complex with a large number of environment branches. In addition, it requires discipline to guarantee that commits follow the correct flow.

GitLab Flow seeks a balance between the simplicity of GitHub Flow and the structure of Gitflow, offering more options to manage different environments and releases. As an alternative to Gitflow, the emphasis on alignment with specific environments suggests that GitLab Flow was designed to address some limitations of GitHub Flow in more complex deployment scenarios.

Other Strategies

In addition to the main strategies, there are other approaches that may be suitable for specific scenarios:

Main-Only Strategy: In this strategy, the main branch is used for both development and deployment. It is a simple approach suitable for small teams or very simple projects, but it is not scalable for larger projects or teams with many contributors.
Release Branching: In this strategy, separate branches are maintained for each software release version. This approach is useful for maintaining a clear history of all releases and guaranteeing that the main branch remains stable and ready for new features. It also facilitates the application of patches and bug fixes in specific versions without affecting others.

Comparing the Strategies

To help visualize the differences between the main Git branching strategies, the following table summarizes their characteristics, advantages, and disadvantages:

Differences between the main Git branching strategies (author)

How to Choose the Right Strategy for Your Project

Selecting the ideal branching strategy is not a trivial decision and depends on a variety of interconnected factors.

The size and structure of the development team play a crucial role. Smaller teams may find simpler strategies such as GitHub Flow or Main-Only more suitable, while larger teams may benefit from the organization and structure of GitLab Flow.

The complexity and scope of the project are also important considerations. More complex projects generally require more organization.

The frequency and type of releases (continuous versus versioned) significantly influence the choice. Teams practicing Continuous Integration and Continuous Delivery (CI/CD) usually lean toward GitHub Flow or Trunk-Based Development.

Team maturity and discipline should also be considered. Trunk-Based Development, for example, requires a high level of discipline and robust automated testing to avoid instability in the main branch.

The need to support multiple simultaneous versions is another important factor. If the project requires maintaining several production versions, Gitflow or Release Branching may be more appropriate.

Compliance requirements and the organization's specific release processes can also influence the decision. Some industries may have stricter release processes that align better with structured strategies such as Gitflow.

The type of product and its release method are also relevant. For example, mobile applications with defined release windows may benefit from strategies such as Gitflow or GitLab Flow with release branches.

Finally, the team's risk tolerance may play a role in the decision. Strategies with more frequent integration, such as TBD, may require greater confidence in automation and testing.

Choosing a branching strategy is not an isolated decision, but one that should align with team culture, project goals, and software delivery processes.

Conclusion

Choosing the ideal Git branching strategy is a crucial decision that directly impacts how a development team collaborates and delivers software. The main strategies discussed — Trunk-Based Development, Feature Branching, Gitflow, GitHub Flow, and GitLab Flow — offer different approaches with their own advantages and disadvantages. The Main-Only strategy and Release Branching address more specific needs.

The selection of the most appropriate strategy should be carefully considered, taking into account team size, project complexity, release frequency, CI/CD requirements, and team maturity. There is no single solution for every scenario, and the chosen strategy should align with the specific goals of the project and the team's culture.

Adopting a branching strategy is only the first step. Writing commit messages with purpose helps maintain a clear and useful project history. The consistent application of best practices, such as naming conventions, frequent merges, code reviews, and automated testing, is essential to guarantee an effective workflow and the delivery of high-quality software.

How I responded to a Supply Chain attack before it hit my project

Vinicius de Santana — Mon, 18 May 2026 20:15:47 +0000

If you work within the modern JavaScript/TypeScript ecosystem, there is a very high chance you are using a TanStack library. Whether it's the omnipresent TanStack Query (formerly React Query), Table, or the newer React Router, they are pretty much everywhere.

The attack

And May 11, 2026, definitely gave a lot of developers a stomachache.

For those who missed it, the TanStack ecosystem suffered a critical supply chain compromise (CVE-2026-45321). A threat actor managed to compromise TanStack's CI/CD pipelines through a "Pwn Request" (cache poisoning via pull_request_target in GitHub Actions), successfully publishing 84 malicious versions across 42 discrete packages. While the main blast radius targeted @tanstack/react-router, the entire stack flashed red.

The worst part about this type of attack? The malicious code executes immediately the moment you or your build server runs an innocent npm install.

"Crisis Mode" Activated: What I did first

When a CVE like this lands on your lap, there's no point in panicking; you need data. My priority was isolating the blast radius using three basic steps:

Timeline Cross-Referencing vs. CI/CD Logs

The very first thing I did was open the official TanStack post-mortem to grasp the exact exposure window (the timeline from when the malicious packages became available on npm to when they were officially pulled).

With those timestamps in hand, I went to our CI/CD server logs. I needed to answer one crucial question: "Did we run any automated build or deploy pipelines during this specific timeframe?".

Fortunately, the result was negative. Our servers hadn't touched npm while the attack was live. First line of defense: OK.

Local Dependency Auditing

Even with the server secure, the danger often lurks right next door: developer machines. Since we use packages like @tanstack/vue-query and @tanstack/query-core, there was a realistic risk that someone on the team could have run npm install locally and pulled a compromised version.

I immediately alerted the team to pause all local installations and initiated a dependency scan to ensure no one was stuck on an attacker-built version.

Leaving a Paper Trail (Governance)

Once the immediate risk was mitigated, I spent some time putting together a technical incident report. It might look like bureaucracy on the surface, but documenting the event chronology, what systems were validated, and logging a final status of "Not Compromised" is what separates a team that "got lucky" from a team with mature governance workflows.

How to make sure your environment is clean

If you think you might have been exposed over the past week, the path forward recommended by the TanStack team involves:

Force the update: Move immediately to the patched versions they released right after the incident.
Nuke local cache: Changing your package.json isn't enough. Delete your node_modules folder, delete your package-lock.json (or equivalent), and completely wipe your package manager cache (npm cache clean --force).
Host Inspection: The malicious script attempts to spread or harvest environment data. It's well worth checking out the Detection section in their official post-mortem to hunt down any anomalous processes or mutations within your .npm directory.

Full post-mortem can be read at: Postmortem: TanStack npm supply-chain compromise

Lessons for the future (An Architecture Perspective)

Incidents like this remind us that our software architecture is only as strong as the weakest link in our dependency supply chain.

Monitoring CVEs manually simply doesn’t scale. As a takeaway from this scare, our next step here is refining our CI/CD pipelines to bake in SCA (Software Composition Analysis) tools more aggressively, automatically breaking the build if a package-lock.json tries to sneak through with a compromised dependency.

What about you? How did you find out about this attack, and did you manage to run diagnostics on your project in time?