Branching Strategies: Trunk-Based, Feature & Release ·…

Why Branching Strategy Matters

Simple explanation

Think of a highway system.

A single-lane road (trunk-based) is fast when traffic is light — everyone moves at the same speed, no merging hassle. But one slow car blocks everyone.

A multi-lane highway (feature branching) lets cars travel at different speeds. Each lane has its own space. But eventually everyone needs to merge back onto the exit ramp — and that’s where traffic jams happen.

A highway with scheduled on-ramps (release branching) controls when cars enter the main road. Great for managing flow, but adds wait time.

Branching strategies are how your team manages parallel work. The right strategy depends on team size, release cadence, and risk tolerance — just like road design depends on traffic patterns.

The Three Branching Strategies

Branching Strategy Comparison
Aspect	Trunk-Based Development	Feature Branching / GitHub Flow	Release Branching / Git Flow
Long-lived branches	Only main (trunk)	Only main; short-lived feature branches	main, develop, release/, hotfix/
Branch lifetime	Hours (or direct commits to trunk)	Days (1-3 days ideally)	Weeks to months for release branches
Merge frequency	Multiple times per day	When feature is complete (daily ideal)	At release cut and hotfix backport
Merge conflict risk	Very low (changes are small and frequent)	Moderate (longer branches = more drift)	High (long-lived branches diverge significantly)
Deployment model	Continuous deployment — every commit is releasable	Continuous delivery — merge to main triggers deploy	Scheduled releases — deploy when release branch is ready
Feature flags needed?	Yes — incomplete features hidden behind flags	Optional — feature is complete before merge	No — features batch into releases
Code review	Pair programming or post-commit review	Pull request review before merge	Pull request review + release branch approval
Team size	Small, senior teams (high trust)	Any size team	Large teams with multiple release trains
Risk tolerance	High — must have excellent CI and monitoring	Moderate — PR review catches issues	Low — extensive testing before release
Rollback strategy	Feature flags or revert commit	Revert the merge commit	Hotfix branch from release tag
Best for	SaaS with CD, microservices	Most teams — balanced flexibility	Mobile apps, on-prem software, regulated releases
DORA impact	Highest deployment frequency, lowest lead time	High deployment frequency if branches are short-lived	Lower deployment frequency, but controlled risk

Trunk-Based Development (TBD)

In trunk-based development, there is one branch — main (the trunk). All developers commit directly to main or use very short-lived branches (hours, not days) that merge back immediately.

Key requirements for TBD to work:

Excellent CI — every commit runs the full test suite; broken trunk blocks everyone
Feature flags — incomplete features are deployed but hidden behind flags
Small commits — changes are tiny and self-contained
Pair programming or post-commit review — no PR bottleneck

☁️ Jordan’s Trunk-Based Setup

Jordan at Cloudstream Media runs trunk-based development for their infrastructure-as-code:

main ─────●───●───●───●───●───●───●───●──── (always deployable)
           │       │           │
          flag    flag       flag
          on      on         on

Every Bicep template change goes directly to main. Feature flags control which infrastructure components are active. Chen (SRE) monitors deployments — if a flag causes issues, they toggle it off instantly without a rollback.

Question

What is the primary prerequisite for trunk-based development to succeed?

Click or press Enter to reveal answer

Answer

Comprehensive automated testing (CI) that runs on every commit. Since all developers commit to the same branch, a broken commit blocks everyone. The test suite must catch issues before they reach main. Additionally, feature flags are essential to deploy incomplete features safely.

Click to flip back

Feature Branching and GitHub Flow

Feature branching creates a separate branch for each feature or bug fix. The branch is developed independently, reviewed via pull request, and merged back to main when complete.

GitHub Flow is the most popular variant: one main branch + short-lived feature branches + PR review + merge to main + deploy.

main ────────●───────────────●────────────●──────── (always deployable)
              \             /              \       /
               ●───●───●──●                ●───●──●
               feature/login               feature/dashboard
               (2 days)                    (3 days)

🚀 Kai’s GitHub Flow at Launchpad Labs

Kai’s team follows strict GitHub Flow:

Riku creates feature/claims-upload from main
Commits multiple times over 2 days
Opens a PR when ready (or draft PR for early feedback)
Zoe reviews, CI runs, all checks pass
Squash merge into main
Automated deployment to production

Kai’s rule: No feature branch lives longer than 3 days. If a feature is too large, break it into smaller PRs behind a feature flag.

Question

What problem occurs when feature branches live too long?

Click or press Enter to reveal answer

Answer

Merge conflicts increase exponentially as the branch drifts from main. Other changes merged to main create conflicts with the long-lived branch. This is called 'merge hell' or 'integration debt.' The solution: keep feature branches short-lived (1-3 days), merge frequently, and break large features into smaller increments.

Click to flip back

Release Branching (Git Flow)

Release branching adds structured branches for managing scheduled releases. The most well-known model is Git Flow by Vincent Driessen.

Git Flow branches:

Branch	Purpose	Lifetime
`main`	Production code — every commit is a release	Permanent
`develop`	Integration branch — features merge here first	Permanent
`feature/*`	Individual features branched from `develop`	Days to weeks
`release/*`	Stabilisation branch for an upcoming release	Days to weeks
`hotfix/*`	Emergency fix branched from `main`	Hours to days

Flow:

main ──────●────────────────────────●──────●─────── (production)
            \                      /      / \
             \    release/1.2 ────●      /   hotfix/1.2.1
              \  /                      /
develop ──●───●───●───●───●───●───●────●────────── (integration)
           \     / \     /
            ●──●    ●──●
           feat/A  feat/B

🏢 Nadia’s Release Branching at Meridian

Meridian Insurance ships quarterly releases — Git Flow fits perfectly:

Features merge to develop throughout the quarter
Week -4: Rashid (platform lead) creates release/Q3-2026 from develop
Weeks -4 to 0: Only bug fixes go into the release branch. New features continue on develop for next quarter
Release day: release/Q3-2026 merges to main (tagged v3.0) and back to develop
Emergency: If production breaks, Nadia creates hotfix/Q3-fix1 from main, fixes, merges to both main and develop

Elena (compliance) loves release branches because there’s a clear audit trail of what went into each release, and the stabilisation period allows thorough regression testing.

Choosing the Right Strategy

The exam will give you a scenario and ask which strategy fits best. Here’s the decision framework:

Scenario	Recommended Strategy	Why
SaaS product with continuous deployment	Trunk-based or GitHub Flow	Need fast, frequent releases
Mobile app with app store releases	Release branching (Git Flow)	App store requires versioned releases
Startup with 5 developers	GitHub Flow	Simple, fast, no overhead
Enterprise with compliance requirements	Release branching	Auditable release process with stabilisation
Microservices with independent deployments	Trunk-based per service	Each service deploys independently
Open-source project with external contributors	Feature branching with forks	Contributors can’t commit to main
Regulated environment (healthcare, finance)	Release branching with long stabilisation	Extended testing and approval required

Question

When should you choose release branching over trunk-based development?

Click or press Enter to reveal answer

Answer

When you have: 1) Scheduled releases (not continuous deployment), 2) Compliance requirements demanding a stabilisation/testing phase before release, 3) Multiple teams contributing to a single codebase with different timelines, 4) Versioned products (mobile apps, on-prem software). If you deploy continuously to a SaaS product, trunk-based or GitHub Flow is usually better.

Click to flip back

Exam Tip: Different Teams, Different Strategies

A common exam scenario: an organisation has multiple teams with different needs. The answer is that different teams can use different branching strategies within the same organisation. Kai’s startup team uses GitHub Flow while Nadia’s enterprise team uses Git Flow — both within the same Azure DevOps organisation. The strategy should match the team’s deployment model and risk profile, not be enforced organisation-wide.

🏛️ Amira’s Regulated Client

Dr. Amira advises Major Collins’ defence project on branching strategy. Requirements: every release must be auditable, tested for 6 weeks, and approved by three stakeholders before deployment. Amira recommends Git Flow with extended release branches — the release branch stays open for the entire 6-week stabilisation while the development team continues feature work on develop.

Farah (junior consultant) asked why not trunk-based: “Because trunk-based assumes you can deploy any commit to production. Major Collins can’t deploy anything without a 6-week test cycle and three sign-offs. The strategy must match the constraints.”

Question

What is the key difference between GitHub Flow and Git Flow?

Click or press Enter to reveal answer

Answer

GitHub Flow has ONE long-lived branch (main) with short-lived feature branches — designed for continuous deployment. Git Flow has TWO long-lived branches (main and develop) plus release and hotfix branches — designed for scheduled releases. GitHub Flow prioritises simplicity and speed. Git Flow prioritises release management and stabilisation.

Click to flip back

Knowledge Check

Kai's startup has 8 developers shipping a SaaS product with continuous deployment to production multiple times per day. Which branching strategy should Kai use?

Knowledge Check

Nadia's team at Meridian Insurance ships quarterly releases to production. Compliance requires a 4-week stabilisation period before each release. During stabilisation, the development team should continue working on next quarter's features. Which branching strategy supports this?

Knowledge Check

An organisation has three teams: a SaaS platform team (deploys daily), a mobile app team (ships monthly to app stores), and an internal tools team (6 developers, deploys weekly). What branching approach should the organisation adopt?

Scenario: Migrating from Classic to Modern Branching

Nadia’s team is migrating from a legacy branching model (one long-lived develop branch with quarterly merges to main) to a modern approach. Her migration plan:

Phase 1: Clean up stale branches (42 abandoned feature branches deleted)
Phase 2: Implement branch policies on main and develop (required reviewers, build validation)
Phase 3: Enforce short-lived feature branches (max 1-week lifetime, automated stale branch warnings)
Phase 4: Introduce Git Flow formally with documented release process
Phase 5 (future): Evaluate moving high-velocity services to GitHub Flow as the team matures

The migration is gradual — you don’t flip a 200-person engineering org overnight.

Next up: Pull Requests: Policies, Protections & Merge Rules