█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Software Engineering/Git and GitHub Pro/Branching Strategies
40 minIntermediate

Branching Strategies

After this lesson, you will be able to: Compare Git Flow, trunk-based development, and feature-flag-driven workflows, and pick the right one for a given team and product.

Branching strategy is the most-debated and least-thought-about part of Git. This lesson maps the three modern approaches and the contexts where each shines.

Prerequisites:Git Internals

Git Flow (the heavyweight legacy)

Five branch types: main, develop, feature/*, release/*, hotfix/*. Releases cut from develop, hotfixes land on main and back-merge. Designed for shrink-wrapped software with quarterly releases (Vincent Driessen, 2010). Still common in regulated industries (banks, healthcare) where releases batch deliberately. Overkill for most web products today.

Trunk-based development (the modern default)

One long-lived branch (main / trunk). Every change goes through a short-lived feature branch (1-3 days max) that merges back to trunk via PR. Releases are tags on trunk, deployed via CI/CD. Used at Google, Facebook, Netflix, most modern SaaS. Trade-off: requires good test automation and feature flags to merge half-finished work safely.

Feature flags as a branching strategy

Instead of long-lived branches, merge code behind a flag that controls whether the feature is enabled. New code ships dark; you flip the flag to enable for 1%, 10%, 100% of users. Tools: LaunchDarkly, GrowthBook, GitHub Actions environments, Vercel feature flags, or a simple `if (process.env.NEW_FEATURE)` for small teams. Lets trunk-based development handle multi-week features without long-lived branches.

A simple feature flag in TypeScript

Boring is good. The pattern works for any size project.

python
// src/flags.ts
export const flags = {
newCheckout: process.env.FLAG_NEW_CHECKOUT === "true",
experimentalRag: process.env.FLAG_EXPERIMENTAL_RAG === "true",
} as const;
// usage
import { flags } from "@/flags";
if (flags.newCheckout) {
return <NewCheckout />;
}
return <LegacyCheckout />;
// For per-user gating, swap process.env for a function that
// checks the user's GrowthBook / LaunchDarkly attributes. The
// caller code stays the same shape.

Picking a strategy

Solo / very small team: trunk-based with optional feature branches. No process overhead. Mid-size product team (5-50 engineers): trunk-based + feature flags. The web-product default. Regulated / shrink-wrap / monthly+ release cycle: Git Flow or a variant. The release branches map to compliance gates. Whatever you pick, document it in CONTRIBUTING.md so new hires don't guess.

Common mistakes only experienced engineers avoid

Letting feature branches live for weeks. Merge conflicts grow exponentially with time. Using Git Flow at a startup. The ceremony slows you down without buying anything you need. Trunk-based without feature flags and without CI tests. You'll ship half-finished features and break trunk regularly. Flag cleanup never happens. Schedule a quarterly flag-removal sprint or flags become permanent dead code.

Quick Check

Your 12-person team works on a SaaS product with multiple deploys per day. Which strategy fits?

Pick the modern default.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Git Internals: Commits, Trees, and Blobs
Back to Git and GitHub Pro
Rebasing vs Merging→