Git Flow and Trunk-Based Development
Beyond the basic feature branch workflow, teams often adopt a named branching strategy to standardize how releases, hotfixes, and ongoing development interact. Git Flow, popularized by Vincent Driessen in 2010, prescribes a rich set of long-lived and short-lived branch types with specific rules for how they connect. Trunk-based development takes the opposite philosophy: minimize branching altogether, keep everyone integrating into a single shared trunk as frequently as possible, and lean on feature flags and strong automated testing instead of branch structure to manage risk. Neither is universally 'correct' — they solve different problems and fit different release cadences and team sizes.
Cricket analogy: Like a team choosing between a rigid, multi-stage domestic-to-international selection pipeline (Git Flow) versus fast-tracking promising players straight into the senior squad with strong fitness testing as the safety net (trunk-based) — both approaches work, suited to different team structures.
Git Flow's branch model
Git Flow defines two permanent branches: main, which always reflects production-released code, and develop, which integrates completed features ahead of the next release. Feature branches (feature/*) branch from and merge back into develop. When it's time to prepare a release, a release/* branch is cut from develop for final stabilization and version bumping, then merged into both main and develop. Urgent production fixes get their own hotfix/* branches cut directly from main, merged back into both main and develop once resolved. This gives strong isolation between in-progress work and what's actually shipped, at the cost of considerable branch-management overhead.
Cricket analogy: Like a board keeping the official Test squad (main) separate from a developmental squad where new techniques are tried (develop), individual net sessions (feature branches) feed into develop, a warm-up tour (release) stabilizes the squad before both squads absorb it, and an injury replacement (hotfix) is called up straight into the Test squad and later folded back into the development squad too.
# Git Flow style release process (illustrative, using plain git — the git-flow
# extension automates these same steps)
git checkout develop
git checkout -b release/2.4.0
# bump version files, final QA fixes
git checkout main
git merge --no-ff release/2.4.0
git tag -a v2.4.0 -m "Release 2.4.0"
git checkout develop
git merge --no-ff release/2.4.0
git branch -d release/2.4.0
# A hotfix branched directly from main
git checkout main
git checkout -b hotfix/2.4.1-auth-crash
# fix, commit
git checkout main && git merge --no-ff hotfix/2.4.1-auth-crash
git checkout develop && git merge --no-ff hotfix/2.4.1-auth-crashTrunk-based development
Trunk-based development asks engineers to merge small changes into a single trunk (usually main) at least daily, sometimes multiple times a day, using very short-lived branches (hours, not weeks) or even committing straight to trunk with pair review. Instead of a long-lived develop branch holding unreleased work, incomplete features are hidden behind feature flags so trunk can be deployed at any time regardless of what's still in progress. This model depends heavily on a fast, reliable CI pipeline and a culture of small, safe, frequently-integrated changes — the tighter the feedback loop, the less risky each individual integration is.
Cricket analogy: Like a domestic team integrating small technique tweaks into match-day form almost daily rather than saving them for a big overhaul, hiding an unproven scoop shot from match situations behind a "not yet match-ready" tag until the coach clears it, relying on constant net-session feedback to catch flaws early.
Choosing between them
Git Flow tends to suit projects with scheduled, versioned releases — desktop software, libraries with semantic versioning, or products supporting multiple release lines in parallel (e.g. maintaining 2.x while developing 3.x). Trunk-based development tends to suit products deployed continuously, such as most SaaS web applications, where 'release' is a fuzzy, constant process rather than a discrete event. Many teams today land somewhere between the two: a simplified 'GitHub Flow' with just main plus short feature branches and PRs, without Git Flow's develop/release/hotfix ceremony.
Cricket analogy: Like a scheduled bilateral Test series with fixed squad announcements suiting the formal Git Flow approach, versus a T20 league where the XI can change every single match suiting trunk-based, with many franchises landing on a simplified middle ground of just naming the playing XI and reviewing it before each game.
GitHub Flow — main plus short-lived feature branches merged via pull request, deployed straight from main — is essentially trunk-based development wearing Git Flow's vocabulary; it's the de facto default for most modern web teams.
Adopting full Git Flow for a continuously deployed SaaS product often backfires: the develop/release branch ceremony adds process overhead without matching a real discrete release cadence, and features can sit unreleased in develop far longer than intended.
- Git Flow defines main, develop, feature/*, release/*, and hotfix/* branches with strict merge rules between them.
- Trunk-based development minimizes branching, favoring frequent small integrations into a single trunk.
- Trunk-based development relies on feature flags to hide incomplete work rather than isolating it on long-lived branches.
- Git Flow suits versioned, scheduled releases; trunk-based development suits continuous deployment.
- GitHub Flow is a lightweight middle ground: main plus short feature branches merged via pull request.
- The right strategy depends on release cadence, team size, and CI maturity, not on which is 'more advanced'.
Practice what you learned
1. In Git Flow, which branch is cut directly from main to address an urgent production bug?
2. What technique does trunk-based development rely on to keep incomplete features from affecting production while still merging frequently to trunk?
3. Which type of project is generally best suited to Git Flow's full branch model?
4. What best describes GitHub Flow relative to Git Flow?
5. In Git Flow, where do completed feature branches typically get merged?
Was this page helpful?
You May Also Like
Feature Branch Workflow
A widely used team workflow where every change lives on its own short-lived branch off main, gets reviewed via pull request, and is merged once approved and tested.
Pull Requests and Code Review
How pull requests turn a branch into a reviewable, discussable proposal for merging code, and the practices that make code review effective rather than a rubber stamp.
Creating and Switching Branches
Master the day-to-day commands for creating, switching, listing, and deleting branches, including the modern git switch/git restore split from git checkout.
Git Tags and Releases
Understand how git tags mark specific commits as meaningful milestones like versions, and how lightweight vs annotated tags support release workflows and reproducible deployments.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics