A team that handles a public app, three distribution tracks and a regulator-friendly audit trail is not the same as a side project on GitHub. Trello's Android team — now under Atlassian — landed on a model called Three Flows after their original "just merge into main" setup collided with Sarbanes-Oxley rules and the messy reality of hot-fixing older releases.
The short version
- Trello's Android team originally used main plus ad hoc release branches.
- Atlassian's SOX compliance made creating and deleting branches expensive.
- GitHub Flow's continuous deployment assumption did not fit Android release mechanics.
- Three Flows keeps three stable branches: main, candidate and release.
- Feature flags replace long-lived feature branches.
Why the old model broke
The original strategy was the kind teams sketch on a whiteboard and never revisit. Main was always supposed to be shippable. Release branches appeared when a feature cluster needed extra hardening. Pull requests carried everything else.
That works until a hotfix to an older release has to flow forward into main and into a half-built release branch simultaneously. Merge paths multiply. Cherry-picks multiply. Confusion multiplies. Add a growing team and the chat thread about where a fix should land starts eating the day.
SOX compliance made the operational cost of branches worse. Every SOX-compliant branch creation and deletion had overhead. Branches were not free any more.
How Three Flows works
Three stable branches: main for daily development, candidate for the next beta, release for the production track. Work happens on short-lived feature branches off whichever stable branch is the target.
When a new beta is ready, main is merged into candidate. When candidate is stable enough, it merges into release. Bug fixes during candidate go into candidate and back down to main. Hotfixes on release go into release, then forward into candidate and main. Direct merges between main and release are forbidden; everything passes through candidate.
Feature flags carry unfinished work so a half-baked feature can ride along in candidate or release with the switch off.
Our analysis
For teams shipping mobile apps, three-flow style models are closer to reality than GitHub Flow. You cannot redeploy a phone in someone's hand. You ship one version, watch it, patch it, move on. The discipline of always routing through candidate is the price you pay for a model that does not collapse the moment a hotfix lands.
The cost is real: every promotion from main to candidate to release is a merge event, and merges between long-lived branches are the traditional source of pain. The model survives because the team avoids long-lived feature branches and leans on flags instead, which keeps the diff between stable branches small most of the time.
If you are a single Android dev shipping weekly, this is overkill. If you are a team with auditors, three distribution tracks and a customer base that does not update on release day, it earns its keep.
Who should care
| Team type | Verdict |
|---|---|
| Mobile teams with audit requirements | Ideal fit |
| Small teams or solo devs | Overkill |
| Web teams with continuous deployment | GitHub Flow is better |
| Teams with multiple distribution tracks | Three Flows handles this well |
What to watch next
Watch how teams layer release trains or trunk-based development on top of three-flow patterns as feature flag platforms mature. The branch count will likely shrink further, with candidate and release surviving because mobile still cannot redeploy at will.
Bottom line: if your context includes mobile releases, auditors or a beta track, steal this. If you ship a web app every hour, keep GitHub Flow.
Key takeaways
- Three Flows uses main, candidate and release as the only long-lived branches.
- All promotions pass through candidate; main and release never merge directly.
- Feature flags replace long-lived feature branches and keep diffs small.
- The model suits Android teams more than web teams that deploy continuously.
Frequently asked questions
What is the Three Flows branching strategy?
It is a Git model with three long-lived branches — main, candidate and release — where every promotion goes through candidate and feature flags replace long-lived feature branches.
Why is GitHub Flow not enough for Android?
GitHub Flow assumes continuous deployment. Android apps cannot redeploy onto devices already in users' hands, so a model that mirrors real release tracks works better.
How do SOX rules affect branching?
Creating and deleting branches can require audit-friendly process steps, which makes ad hoc branching painful. Three Flows keeps the branch set stable to limit that overhead.
Where do feature branches live in this model?
On whichever stable branch is the target — typically main — and they stay short-lived thanks to feature flags.
Is this overkill for a small team?
Usually yes. If you are shipping a mobile app with a small team and no audit pressure, a simpler main-plus-release approach is fine.