Git Flow vs Trunk-Based: Mobile Branching Guide

A mobile team always hits the same question at the start of a new sprint: should feature branches live for weeks, or should everyone commit straight to a single line? The git flow vs trunk based development choice isn't a simple style preference for mobile teams; it's a real architectural decision driven by store review, release trains, and hotfix pressure. In this guide you'll find a sourced, actionable roadmap covering both models' history and a mobile-specific decision framework.

💡 Pro Tip: Don't ask "which one is more modern" — ask "how many of our releases are living in the wild at the same time." That question takes you straight to the right model.

Table of Contents

• Defining the Two Models and Their History
• What Makes Mobile Teams Different
• The Real Cost of Git Flow on a Mobile Project
• Prerequisites for Trunk-Based
• Continuous integration infrastructure
• Feature flag infrastructure
• A lightweight code review culture
• Hybrid: Release Branch + Trunk (Release Train)
• Version Numbering and Branch Naming
• Decision Framework
• Transition Plan: From Git Flow to Trunk-Based in 4 Weeks
• Week 1: Make CI run daily
• Week 2: Cut the branch count to 3
• Week 3: Set up feature flag infrastructure
• Week 4: Run your first release train
• Common Mistakes
• FAQ
• What is the difference between Git Flow and trunk-based development?
• Which branching strategy is better for mobile app teams?
• Is a feature flag required for trunk-based development?
• Is a release branch the same thing as a hotfix branch?
• Should I move to trunk-based if my CI isn't mature yet?
• Update (September 2026)
• Conclusion
• Sources

Defining the Two Models and Their History

Git flow was defined by Vincent Driessen in 2010. At the model's center are two infinite-lived branches: master, which always reflects a production-ready state, and develop, "the integration branch that reflects the state of the latest delivered development changes for the next release." On top of these sit feature/*, release/*, and hotfix/* branches.

In 2020, Driessen added a "reflection" note to his own model, writing: "If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team." In the same note he also drew the boundary: "If you are developing software that is explicitly versioned, or that you need to support multiple versions of in the wild, then git-flow may still be a good fit for you." Mobile apps fall squarely into this second category: multiple build versions can be in users' hands in the store at the same time, and each version may need to be supported separately.

Trunk-based development works on the opposite philosophy: developers collaborate on a single branch called "trunk" and resist pressure to create other long-lived development branches. In the git world this branch has mostly been named main since 2020. Trunkbaseddevelopment.com's own scale evidence is striking: Google practices trunk-based development, with 35,000 developers and test automation engineers working on a single monorepo trunk.

Google Cloud's DORA (dora.dev) research program defines trunk-based development as a practice where "developers merge individual changes into a shared trunk frequently, and branches rarely if ever live longer than a few hours," and it gives three concrete rules: "Have three or fewer active branches. Merge branches to trunk at least once a day. Don't have code freezes or integration phases." These rules are based on the 2016 and 2017 State of DevOps reports.

What Makes Mobile Teams Different

Rolling back a bug you notice in a web deploy takes minutes. Mobile is different: App Store and Play Store distribution involve an "instantly irreversible" release step — once a build enters the review queue, it's out of your control until it's approved. This structural difference explains why git-flow's release and hotfix branches still make sense on mobile: in trunkbaseddevelopment.com's own words, "it is common for trunk-based development teams to create a release branch on a just-in-time basis, for example a few days before a release."

This release branch's rule is also clear; per the principle from Wingerd and Seiwald's classic 1998 whitepaper, a release branch "should not receive ongoing development work." So the release branch is frozen and only receives targeted bug fixes (via cherry-pick); new feature development continues on trunk. Teams doing continuous delivery (CD) don't use a release branch at all; instead they choose a "roll-forward" strategy — a bug fix lands on trunk and production is released directly from trunk. On mobile, pure roll-forward can't be applied directly to production because store review gets in the way, but the principle still holds: a hotfix's source should be trunk, not a forgotten old branch.

Hotfix needs can be met in both models: with git-flow's own hotfix/* branch, or with a cherry-pick into trunk-based's release branch. The difference is where daily development lives — on develop in git-flow, directly on main in trunk-based.

The Real Cost of Git Flow on a Mobile Project

Driessen's own 2020 note says git-flow is too heavy for teams doing continuous delivery. The reverse is also true: long-lived develop and feature/* branches lead to large, infrequent merge events. DORA's "no code freeze or integration phase" rule is exactly the opposite of this scenario — once develop accumulates changes for weeks, a pre-release "integration week" becomes inevitable.

Another obstacle DORA points to in its "Common pitfalls" section relates to code review culture: "Many organizations use a heavy code review process that requires multiple approvals before changes are merged to trunk." DORA adds in the same section: when code review is laborious and takes hours or days, developers avoid working in small batches. Long-lived branches feed this heavy review process: the bigger a PR grows, the more its review is delayed, and the delay stretches the branch's lifetime even further — a vicious cycle.

1# A typical merge-conflict scenario in git flow
2git checkout develop
3git pull origin develop
4git merge feature/payment-v2
5# CONFLICT (content): Merge conflict in Sources/Payment/PaymentViewModel.swift
6# for example, a feature branch open for weeks is trying to catch up with dozens of commits on develop

Prerequisites for Trunk-Based

Trunk-based development operates on a "discipline first, branches second" logic. Trying it on mobile without three prerequisites is risky.

Continuous integration infrastructure

DORA's Continuous Integration definition is clear: "You should be able to successfully run your build process at least once a day... Your tests should also run successfully at least once a day." The 2015 State of DevOps Report shows that teams whose developers merge their work to trunk at least once a day perform better. On mobile, this means a CI pipeline (e.g. Xcode Cloud, Bitrise, or GitHub Actions + fastlane) that runs simulator/device tests on every PR.

1# .github/workflows/pr-check.yml — mandatory gate before merging to trunk
2on:
3  pull_request:
4    branches: [main]
5jobs:
6  test:
7    runs-on: macos-15
8    steps:
9      - uses: actions/checkout@v4
10      - run: sudo xcode-select -s /Applications/Xcode_26.0.app
11      - run: xcodebuild test -scheme App -destination 'platform=iOS Simulator,name=iPhone 17'

Feature flag infrastructure

Martin Fowler named this technique "Feature Toggles"; trunkbaseddevelopment.com prefers the more common industry term "Feature Flags." Whatever you call it, the logic is the same: an unfinished feature enters trunk early but stays off.

1// A simple feature flag: the feature is on trunk but can be switched off
2// AppConfig is your own wrapper around a remote-config provider (Firebase Remote Config, LaunchDarkly, etc.)
3enum FeatureFlag {
4    static var newOnboardingFlow: Bool {
5        AppConfig.shared.bool(forKey: "new_onboarding_flow")
6    }
7}
8 
9func presentOnboarding() {
10    if FeatureFlag.newOnboardingFlow {
11        presentNewOnboarding()
12    } else {
13        presentLegacyOnboarding()
14    }
15}

This way, even an unfinished onboarding flow can land on trunk daily; if the flag is off in the build that goes to the store, the user sees nothing.

A lightweight code review culture

GitHub's flow documentation describes the concrete counterpart of small-PR practice like this: "Ideally, each commit contains an isolated, complete change... if you want to rename a variable and add some tests, put the variable rename in one commit and the tests in another commit." The same documentation also clarifies the purpose of branching: "By creating a branch, you create a space to work without affecting the default branch... it also gives your collaborators a chance to review your work." Small, isolated commits both speed up review and keep trunk continuously healthy.

Hybrid: Release Branch + Trunk (Release Train)

Neither pure git-flow nor pure trunk-based fits mobile distribution constraints directly; a hybrid between the two adapts to these constraints more easily. The practice described on trunkbaseddevelopment.com's "branch-for-release" page forms a natural hybrid for mobile teams: daily development continues on a single main with short-lived branches; a few days before release, a release/x.y branch is cut and frozen — it only accepts targeted cherry-picked fixes. I generally prefer to call this arrangement a "release train" on mobile projects: the train departs on a set date, everything that lands on trunk by then boards it, and the rest waits for the next train.

1# Release train: cut and freeze a branch a few days before release (e.g. 5 days)
2git checkout main
3git pull origin main
4git checkout -b release/4.12.0
5git push origin release/4.12.0
6 
7# Development continues on trunk (for 4.13.0)
8# release/4.12.0 only receives bug fixes via cherry-pick
9git checkout release/4.12.0
10git cherry-pick <hotfix-commit-sha>

In this flow, trunk is never "frozen"; only a specific snapshot of it goes to the store.

Version Numbering and Branch Naming

What keeps a release train sustainable is often naming more than discipline. I generally tie release branches directly to semver — like release/4.12.0, not release/sprint-42 or a date-based name, because the version number must map one-to-one to the build that goes to store review and shouldn't be confused with the build number. The same logic applies to development branches on trunk: a short-lived branch like feature/onboarding-v2 should describe what it does, not who opened it — because in trunk-based development a branch already lives for a few hours to a few days and isn't expected to be a permanent reference point. If you want to track cherry-pick history, adding the original trunk commit SHA to each cherry-pick commit message helps; that way you can read from git log alone which commit a bug fix is on both main and release/4.12.0, without a separate tool. When a release branch closes (i.e. when the next version's train starts), don't delete the old release branch right away — if the store review is rejected or an urgent hotfix is needed, having that branch still around speeds up recovery.

Decision Framework

Use three axes to decide: team size, release frequency, and how many versions you need to support simultaneously. DORA's three rules (3 or fewer active branches, at least one trunk merge per day, no code freeze) and Driessen's binary distinction (continuous delivery → simple flow; explicitly versioned / multi-version support → git-flow) feed directly into this table.

Transition Plan: From Git Flow to Trunk-Based in 4 Weeks

This transition plan doesn't come from a single official source; it's a workable sequence I've built on DORA's CI prerequisites, feature flag practice, and the "3 or fewer active branches" goal.

Week 1: Make CI run daily

First you need to be able to trust trunk. DORA's rule is clear: build and tests should run successfully at least once a day. If there's no automated test pipeline for every PR into develop, set that up first.

Week 2: Cut the branch count to 3

List open feature branches and see which ones have been waiting for weeks. Per DORA's "3 or fewer active branches" target, either finish the remaining work or put it behind a feature flag and merge it into trunk early.

Week 3: Set up feature flag infrastructure

Set up a simple remote-config-based flag system (Firebase Remote Config, LaunchDarkly, or your own solution). Move unfinished work to main behind a flag instead of develop.

Week 4: Run your first release train

Remove the develop branch, make main the single development line. Try a release/x.y branch for your first store release, and make it clear with the team that it only accepts cherry-picks.

Common Mistakes

• Trying trunk-based with a heavy code review process: this is the biggest obstacle DORA points to — trying to move to trunk-based while a slow, multi-approval review process is still in place makes small-PR discipline impossible.
• Trunk-based without CI: without a guarantee of daily build/test, everyone committing directly to main raises the risk of a broken trunk.
• Forgetting the feature flag and leaving unfinished work on trunk: without flag infrastructure, the thinking "an unfinished feature can't go onto trunk" leads right back to long-lived branches.
• Leaking new features into the release branch: Wingerd & Seiwald's 1998 principle still holds — a release branch shouldn't receive ongoing development work. Once it leaks in, the branch turns into a "second trunk" and loses its purpose.
• Abandoning git-flow just because it's "old": Driessen's 2020 note isn't a ban, it's a distinction of context. For mobile products that support multiple versions, git-flow is still a legitimate choice.
• Leaving the hybrid model undocumented: if you're using a release train, write down the rule for "when does what land on trunk, when do cherry-picks go to the release branch" in the team wiki; verbal agreements get forgotten.

FAQ

What is the difference between Git Flow and trunk-based development?

The core difference is branch lifetime. Git flow uses two infinite-lived main branches, master and develop, with feature/*, release/*, and hotfix/* branches built on top of them. Trunk-based development instead works on a single long-lived branch (main/trunk); branches generally don't live longer than a few hours, and developers merge into trunk directly and frequently.

Which branching strategy is better for mobile app teams?

There's no single right answer; it's decided based on the distinction in Driessen's 2020 note. Teams doing continuous delivery with a single active version are better suited to trunk-based (with a release train hybrid if needed). Teams that need to support multiple store versions at once, with a regular QA phase, still find git flow or a git-flow-like release branch structure legitimate.

Is a feature flag required for trunk-based development?

Not strictly required, but in practice it's necessary given the approach trunkbaseddevelopment.com describes. Instead of keeping an unfinished feature on a long-lived branch, integrating it into trunk early and switched off using the technique Fowler calls "Feature Toggles" keeps trunk-based's "short-lived branch" principle sustainable.

Is a release branch the same thing as a hotfix branch?

No. A release branch is a frozen snapshot of a version being prepared for release, and it only receives targeted fixes (Wingerd & Seiwald, 1998). A hotfix branch, specific to git flow, is a short-lived branch opened to urgently fix a bug in production on master. In trunk-based, the same need is met by cherry-picking directly into the release branch.

Should I move to trunk-based if my CI isn't mature yet?

No, mature your CI first. DORA's rule requires build and tests to run successfully at least once a day; without that guarantee, everyone committing directly to main raises the risk of a broken trunk. Don't skip Week 1 of the transition plan (making CI run daily).

Update (September 2026)

This article was written with current tools as of September 16, 2026; developments close to writing time that directly affect branching discipline include:

• September 9, 2026 — GitHub added a rule blocking merges of PRs with exposed secrets. A new repository ruleset rule called "require secret scanning alerts are resolved" arrived (currently in public preview, requires a GitHub Secret Protection or GitHub Advanced Security subscription): if secret scanning hasn't completed for a PR's head commit, or there's an open alert, the merge is blocked. For trunk-based teams, this automates the "every commit must be healthy" principle. Source: github.blog changelog.
• August 11, 2026 — GitHub introduced a tool that automatically migrates old branch protection rules into repository rulesets. Under Settings → Branches, "Convert to ruleset" maps existing rules (required reviews, status checks, push restrictions) to pattern-based rulesets, making it easier for trunk-based teams to move their existing protection rules into the new ruleset model.
• Since April 28, 2026 — iOS/iPadOS apps uploaded to App Store Connect must be built with the iOS 26 & iPadOS 26 SDK or later. For teams whose CI runner is pinned to an older Xcode image, this adds a new "toolchain gate" to the release train: regardless of branching strategy, keeping the CI image up to date is now a prerequisite for submission.
• March 10, 2026 — DORA writes that high AI adoption increases both delivery throughput and delivery instability. According to dora.dev's "Balancing AI Tensions" report, AI acts as an "amplifier" that magnifies both existing strengths and weaknesses. Read through the lens of branch discipline: DORA's 3-or-fewer-active-branches and daily-trunk-merge rules may become even more decisive in AI-assisted development.

Conclusion

The git flow vs trunk based development difference ultimately comes down to branch lifetime and a mobile team's real distribution constraints. Even Driessen's own 2020 note doesn't reject git-flow outright; your release frequency, the number of builds you support simultaneously, and your CI maturity should drive the decision. If you're considering moving to trunk-based, set up CI and feature flag infrastructure first, then try the release train hybrid.

To go deeper on the topic, you can check out these articles: if you want to build a CI/CD pipeline from scratch, take a look at the iOS CI/CD Pipeline: GitHub Actions and Fastlane guide. To review your mobile team's DevOps practices as a whole, Mobile DevOps Best Practices is a good starting point. If you're using Apple's own CI solution, Xcode Cloud Pipeline Optimization (in Turkish) explains how to cut build times and cost. To monitor crash rates on your release train, you can check the iOS Crash Reporting and Analytics guide.

If you want to automate the store submission process, the App Store Connect API 2026 (in Turkish) article details TestFlight and submission automation. If you want to run modular architecture alongside trunk-based development, also check out Modular iOS Architecture and Swift Package Manager (in Turkish).

For the side-by-side summary table and a short decision guide, see the Git Flow vs Trunk-Based comparison page as well.

Sources

• A successful Git branching model — nvie.com — Git flow's original definition and Vincent Driessen's 2020 "reflection" note.
• Trunk Based Development — trunkbaseddevelopment.com — Definition of trunk-based development, the Google example, and the terminology shift.
• Branch for release — trunkbaseddevelopment.com — Just-in-time release branch practice and the frozen-branch rule.
• Feature Flags — trunkbaseddevelopment.com — Feature toggle technique and the Martin Fowler reference.
• Trunk-based development — dora.dev — DORA's three branch-hygiene rules and common pitfalls.
• Continuous integration — dora.dev — The daily build/test rule and the 2015 State of DevOps finding.
• GitHub flow — GitHub Docs — Lightweight, branch-based workflow and the small-commit principle.
• 5 Effective Git Branching Strategies — DeployHQ — A guide referencing nvie's 2020 note.
• Block pull requests with exposed secrets from merging — GitHub Changelog — September 9, 2026, the secret scanning merge rule.
• Automatically migrate branch protection rules to repository rulesets — GitHub Changelog — August 11, 2026, automatic migration tool from branch protection to rulesets.
• Upcoming SDK minimum requirements — Apple Developer — iOS/iPadOS/tvOS/visionOS SDK minimum version requirement in effect since April 28, 2026.
• Balancing AI Tensions — dora.dev — March 10, 2026, the effect of AI adoption on delivery speed and instability.