Which Git workflow? Gitflow, GitHub Flow, and trunk-based
Three questions and a decision matrix for choosing between Gitflow, GitHub Flow, and trunk-based development by product shape, team size, and deploy tempo.
Git · Workflow
Which Git workflow? Decide with three questions
Gitflow and GitHub Flow are both right, for different product shapes. Trunk-based is a decision about tempo. The answer lies not in the meeting but in the product itself.
The mechanics of two models
Gitflow and GitHub Flow
| Topic | Gitflow | GitHub Flow |
|---|---|---|
| Branches | main, develop, feature/*, release/*, hotfix/* | A single main and short-lived branches off it |
| Release | Release-oriented; a separate release branch for each release | No notion of a release; the only live version is the one in prod |
| Hotfix | A separate hotfix/* line | A PR that jumps the queue |
| Natural habitat | Mobile apps, SDKs and libraries, on-premise or packaged software | Web apps and SaaS, internal tools, API services |
Three questions, one default
The product chooses the branch strategy
- Step 1: How many versions are live at once?
One → GitHub Flow. More than one → Gitflow. - Step 2: Does the customer see my deploy frequency?
No, I deploy whenever I want → GitHub Flow. Yes, there is a contract between releases → Gitflow. - Step 3: Must a hotfix go through a release?
No → GitHub Flow. Yes → Gitflow. - Step 4: If the answers are mixed
The product's shape hasn't settled yet; GitHub Flow for now. Moving from it to Gitflow is a small migration, unlike the reverse.
Team and deploy tempo
Three workflows, four situations
The vertical axis shows team size, the horizontal axis deploy tempo. The cells are compiled from the Git in Production guide and the trunk-based post.
Small team ↔ Large team
Gitflow
Versioned product
- Mobile app, App Store distribution
- Versioned package or library: a release branch helps
Trunk-based
In the guide: 50+ developers, 10+ deploys a day
- Continuous deployment culture
- Feature flag infrastructure in place
GitHub Flow or something simpler
3-person freelance agency
- Working directly without PRs is an option too
- In a team under 3, a trunk-based investment doesn't pay off
GitHub Flow
Team of 3-15
- SaaS, CI/CD in place
- One or two deploys a day
Planned, versioned releases ↔ Frequent deploys
From the Git in Production guide
Decision table
| Situation | Recommendation |
|---|---|
| Mobile app, App Store distribution | Gitflow |
| SaaS, small-to-medium team, daily deploys | GitHub Flow |
| 3-person freelance agency | GitHub Flow |
| 50+ developers, 10+ deploys a day | Trunk-based |
| Versioned package or library | Gitflow |
| No plan, “whatever is needed” | GitHub Flow |
When to go trunk-based
Two different thresholds in the posts
- Trunk postOnce deploy frequency reaches 5+ a week, the release branch stops being a structure and starts being an obstacle. Projects where trunk-based is advocated deploy 3-10 times a day.
- Gitflow postAt 5+ deploys a day, even GitHub Flow's short-lived branches become a source of friction; beyond that threshold, trunk-based.
- TipFor a team deploying once a week, there is no reason forcing a move; Gitflow or GitHub Flow works fine at that rhythm.
Trunk-based targets
The numbers that carry the tempo
- 5-10minutesTarget: pipeline time from merge to prod
- 1-2daysThreshold: the longest life of a feature branch
- 200-400linesTarget: size of a PR with a single logical change
- 60-90minutesReview time for a PR of this size
Before you switch
The four foundations of trunk-based
- A green trunk at the contract level: guaranteed by CI and required PR checks (pending)
- Feature flag infrastructure: unfinished work enters the code but stays off for users (pending)
- A fast pipeline: 5-10 minutes from merge to prod (pending)
- A short-lived branch culture: closed the day it's opened or the next (pending)
Trunk-based and measurement
Measure once you switch, and know when not to
Do
- Target for lead time for changes: p50 < 1 hour
- Target for change failure rate: < 15%
- Target for mean time to restore: < 30 minutes
- If the metrics get worse, look at CI and flag discipline first
Don’t
- Don't switch when a regulated sector requires pre-prod sign-off
- Don't switch when 3.x and 4.x must be supported at the same time
- Don't switch on a team that can't guarantee a green CI
- Don't switch on a team under 3 that deploys once a week
Mismatch errors
Putting the model in the wrong place
- Anti-patternMixing the three workflows: a develop branch, feature flags, and a release branch together. Applying half of three separate disciplines means getting the advantage of none.
- Gitflow in SaaSdevelop becomes a needless shadow prod; PRs get merged twice. The isolation you gain isn't worth the friction you pay.
- GitHub Flow in a packaged productWhen a customer on an old version asks for a hotfix, the team goes looking for a maintenance branch that doesn't exist.
- Hybrid modelApplying one of two models correctly is always cheaper than inventing a third.
Decision
Choose your Git workflow for the product; not the product for the workflow.
The choice is not “which is modern” but “which one does your product's shape make natural.” When the number of versions, the customer type, or the deploy frequency changes, the decision reopens.
