Branching Strategies

Trunk-Based Development, GitHub Flow, GitFlow, GitLab Flow and Forking. How to organize branches, releases and hotfixes for your team.

A branching strategy defines how the team uses Git branches: where work is integrated, how long a branch lives, how a release is cut and how a production bug gets fixed.

#The Problem

Without an agreement, everyone uses Git their own way. You get weeks-long branches, giant merges with conflicts, a broken main, releases nobody can describe, and hotfixes lost in the next deploy. The cost of integrating grows with the time spent not integrating.

#The Solution

Pick an explicit strategy and write it down. The variable that matters most is not the name of the flow but how long code takes to reach the main branch. The shorter branches live, the less merges hurt and the faster you reach production.

#How to choose: key questions

  1. How is the software delivered? Continuous deployment (web, SaaS) → Trunk-Based or GitHub Flow. Versions installed by the customer (desktop, mobile, libraries, on-premise) → GitFlow or release branches.
  2. How many versions must you maintain at once? One → simple flows. Several → release branches.
  3. How good is your automation? Without CI and reliable tests, short branches are not safe. With solid CI, Trunk-Based pays off.
  4. Can you hide unfinished work? With Feature Flags you can integrate not-yet-visible code daily.
  5. Who contributes? Trusted team → branches in the same repo. External contributors → Forking.
  6. Are there per-environment approvals (compliance)? → GitLab Flow with environment branches.

The strategy is independent of the deployment style, but they influence each other: a Modulith or a monolith with a single pipeline almost always fits Trunk-Based; versioning contracts between microservices adds release complexity.

#In this chapter

  • Trunk-Based Development — everyone integrates into main at least daily.
  • GitHub Flow — short branches with Pull Request, deploy from main.
  • GitFlow — develop, release and hotfix for versioned software.
  • GitLab Flow — main plus environment or release branches.
  • Forking Workflow — each contributor works on their own fork.
  • Comparison — table and decision tree.
  • Trunk-Based Development — The whole team integrates into a single branch (trunk/main) using very short-lived branches and feature flags.
  • GitHub Flow — main always deployable, short branches per change, Pull Request and deploy after merge.
  • GitFlow — main, develop, feature, release and hotfix. Designed for versioned software with planned releases.
  • GitLab Flow — GitHub Flow plus environment branches (staging, production) or release branches, with an "upstream first" rule.
  • Forking Workflow — Each contributor works on their own fork and proposes changes via Pull Request to the main repository.
  • Branching Strategies Comparison — Comparison table and decision tree to choose between Trunk-Based, GitHub Flow, GitFlow and GitLab Flow.