Compare GitFlow, GitHub Flow and trunk-based development. When does each make sense?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
GitFlow uses long-lived branches (develop, feature, release, hotfix) with formal merges — structured but heavy, suited to scheduled releases and multiple supported versions. GitHub Flow is minimal: main is always deployable, short-lived feature branches merged via PR — ideal for continuous deployment. Trunk-based goes further: developers integrate into main at least daily via tiny short-lived branches, relying on feature flags instead of long branches.
Detailed explanation
GitFlow (Vincent Driessen) models the full release lifecycle: develop integrates features, release/* branches stabilize, hotfix/* patches production, all merging back to both main and develop. It shines when you ship on a cadence and maintain several production versions, but the branch overhead and merge churn are real costs. GitHub Flow strips it down: main is sacred and always deployable; every change is a feature branch opened, reviewed via PR, CI-passed, then merged and deployed. Perfect for web apps deploying many times a day. Trunk-based development pushes integration frequency further — developers merge to main at least daily, using branches that live hours not days, and hide incomplete work behind feature flags rather than long-lived branches. It minimizes merge debt and suits high-velocity teams with strong CI and flag infrastructure. Choosing: regulated/multi-version software leans GitFlow; most SaaS products fit GitHub Flow; elite-velocity teams with mature CI adopt trunk-based. The common thread — pick the simplest model that matches your release cadence and tooling, then enforce it with branch protection and CI.
Example
# GitHub Flow (most web apps):
# main always deployable → feature branch → PR → review → merge → deploy
# Trunk-based (high velocity):
# branch lives < 1 day → PR → merge to main → feature flag gates the UI
# GitFlow (scheduled releases):
# develop ← feature/* → release/* → main + hotfix/*Interview tip
Map each model to a release cadence (continuous / daily / scheduled) and name feature flags as the enabler for trunk-based. That decision framework is what interviewers want, not just definitions.
Common mistakes
- Adopting GitFlow for a simple web app and drowning in branches.
- Doing trunk-based without feature flags, shipping half-finished work.
- Treating the workflow as dogma instead of matching it to release cadence.