Branching Strategies: Trunk-Based, Feature & Release

Why Branching Strategy Matters

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:

1. Excellent CI — every commit runs the full test suite; broken trunk blocks everyone
2. Feature flags — incomplete features are deployed but hidden behind flags
3. Small commits — changes are tiny and self-contained
4. 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:

1. Riku creates feature/claims-upload from main
2. Commits multiple times over 2 days
3. Opens a PR when ready (or draft PR for early feedback)
4. Zoe reviews, CI runs, all checks pass
5. Squash merge into main
6. 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?

AGit Flow with develop, release, and hotfix branchesBGitHub Flow with short-lived feature branches and PR reviewCRelease branching with two-week stabilisation periodsDA single main branch with no feature branches (strict trunk-based)

Check Answer

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?

ATrunk-based development with feature flagsBGitHub Flow with long-lived feature branchesCGit Flow with release branchesDFeature branching with a staging branch

Check Answer

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?

AStandardise on Git Flow across all three teams for consistencyBStandardise on GitHub Flow across all three teams for simplicityCEach team uses the strategy that matches their deployment modelDTrunk-based for all teams with feature flags managing release timing

Check Answer

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:

1. Phase 1: Clean up stale branches (42 abandoned feature branches deleted)
2. Phase 2: Implement branch policies on main and develop (required reviewers, build validation)
3. Phase 3: Enforce short-lived feature branches (max 1-week lifetime, automated stale branch warnings)
4. Phase 4: Introduce Git Flow formally with documented release process
5. 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.

🎬 Video coming soon

Branching Strategies in Practice

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