← Flutter Reference

What is Trunk-Based Development?

CI/CD · Intermediate

By Abdelrahman Saed — Senior Mobile Engineer. Last updated: 2026-08-10.

Trunk-based development is a source control strategy where all developers commit frequently to a single shared branch (the trunk, usually master or main). Feature branches are short-lived (hours to a day or two) and merge back immediately, rather than living for weeks as in GitFlow.

How it works

In trunk-based development, the master branch is always deployable. Engineers create short-lived branches, make small changes, and merge quickly:

master:  ──●──●──●──●──●──●──●──●──●──●──
            \ /    \ /    \ /
feature:    ●●      ●●      ●●

Key practices:

1. Short-lived branches — a branch lives for hours or a day, not weeks. If a feature takes longer, it ships dark behind a feature flag. 2. Small commits — merge one logical change at a time, not a month of work. 3. Branch protection — master rejects direct pushes; every merge goes through CI gates. 4. Feature flags — incomplete work merges dark behind a flag and ramps when ready.

At iStoria, trunk-based development is what let us cut the release cycle from four weeks to one. Engineers merge multiple times per day into a protected master, and a suite of 14 GitHub Actions workflows keeps the trunk green:

• master rejects direct pushes (even from the lead).
• Every PR runs Dart analysis as a merge gate.
• Bots auto-rebase open PRs after each merge, so conflicts never sit unnoticed.

When to use it

Use trunk-based development when:

• You want to ship frequently (weekly or faster).
• You have CI/CD gates that catch issues quickly.
• Your team values fast feedback over long-running "complete" branches.

Use GitFlow instead when:

• You ship infrequently (monthly or slower) and need release branches.
• You have multiple supported versions in production.
• Your team isn't ready for feature flags.

Strengths

• Faster feedback — small merges surface integration issues immediately
• Always-deployable trunk — master is always shippable
• Fewer merge conflicts — branches are short-lived, so they don't drift
• Enables continuous deployment — pair with feature flags for decouple-deploy-from-release
• Forces small, reviewable changes — a 2,000-line PR is a code smell

Tradeoffs

• Requires discipline — engineers must merge small and often
• Needs CI/CD — without automated quality gates, the trunk breaks
• Feature flags are mandatory — you can't hold a merge because the feature isn't ready
• Not suited for multi-version support — use GitFlow if you maintain old release branches

Comparisons

• Fastlane vs Codemagic
• GitHub Actions vs Codemagic
• Feature Flags vs A/B Testing

Related articles

• The repo that rejects my own pushes to master
• PRs that fill in their own paperwork (and a gate that won't let bad code merge)
• Every merge to master quietly breaks other PRs. So I built a radar for it.

Related case studies

• From Four-Week Releases to Weekly

FAQ

What is the difference between trunk-based development and GitFlow?

Trunk-based development merges everything to one branch frequently with short-lived feature branches. GitFlow uses long-lived feature branches and dedicated release branches. Trunk-based enables faster releases (days/weeks); GitFlow suits slower, multi-version release cycles (months).

How do feature flags work with trunk-based development?

Feature flags let you merge unfinished code dark — the code is in master but gated behind a flag that defaults to off. When the feature is ready, you enable the flag remotely (via GrowthBook, Firebase Remote Config, etc.) without a new release. This decouples deploy from release.

---

Available for hire. Abdelrahman Saed is a Senior Mobile Engineer (Flutter) — open to full-time, fractional, contract, or advisory work. Hire me →

Book a 20-minute call · Download the CV (PDF) · See how I work