Trunk-Based Development — What It Is, Principles and Working in a Single Branch

What Is Trunk-Based Development?

Trunk-Based Development (TBD) is a version management methodology where all developers integrate their changes into a single main branch (trunk, main, or master) several times a day. Unlike Git Flow with its long-lived feature branches, TBD minimizes branch lifetime to a few hours, or rarely 1–2 days. The main goal is to avoid merge hell, where a large feature is merged into trunk after weeks of development.

According to Google Cloud DevOps, 2024, Trunk-Based Development is one of the key practices of high-performing DevOps teams. The State of DevOps Report (Puppet, 2023) showed that teams using TBD recover from failures 30% faster and encounter critical production defects 50% less often. TBD is essential for Continuous Deployment.

Trunk-Based Development does not mean developers commit directly to trunk without review. TBD uses short-lived feature branches that, after creating an MR and quick code review (within a few hours), are merged into trunk. If a review takes more than a day, the feature needs to be broken down into smaller parts.

State of DevOps Report: Data on TBD

The annual State of DevOps Report (Puppet/DORA) tracks the practices of high-performing teams. Since 2015, TBD has been in the top 3 practices correlated with high deploy frequency and low Mean Time to Recovery (MTTR). Teams practicing TBD deploy code 2–3 times more often and recover from failures 30% faster (DORA, 2023).

Feature Toggles: Managing Unfinished Code Without Branches

Feature Toggles (feature flags) are a mechanism for enabling and disabling functionality without changing code. In TBD, feature toggles replace feature branches: a developer commits unfinished code to trunk but hides it behind a conditional flag. When the feature is ready for display, the flag is toggled in configuration without redeployment.

According to Martin Fowler, 2024, feature toggles are divided into four types: release toggles (managing feature visibility), experiment toggles (A/B testing), ops toggles (managing operational parameters), and permission toggles (role-based access). In mobile projects, release toggles are especially useful: new functionality is hidden until the release date, but the code is already in trunk and goes through CI/CD.

// Feature Toggle in Android with Kotlin
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

    fun isEnabled(key: String): Boolean {
        return remoteConfig.getBoolean(key)
    }
}

// Usage in code
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD in Trunk-Based Development: Essential Practices

Continuous Integration (CI) is the most important component of TBD. Every push to trunk (or to a temporary branch before MR) triggers a full pipeline: build, unit tests, integration tests, linters, static analysis, code coverage check. If at least one stage fails, the author fixes the code before the next commit. “Broken trunk — stopped development” is the main rule of TBD.

According to Jez Humble, Continuous Delivery, 2024, Trunk-Based Development requires a CI pipeline that completes in 10–15 minutes. If the build takes longer, developers commit less often, which undermines the purpose of TBD. In mobile projects, Android and iOS builds can take 20–30 minutes, making TBD less convenient. In such cases, teams use Short-Lived Feature Branches (1-day branches) with immediate CI.

# GitHub Actions for TBD (Android)
name: CI - TBD Check
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew testDebugUnitTest
      - name: Static analysis
        run: ./gradlew ktlintCheck detekt

Short-Lived Branches: Working Rules in TBD

Short-lived branches are a compromise between pure TBD (commits directly to trunk) and Git Flow. A branch lives no more than 1–2 days, contains changes for 1–3 commits, and after review (no more than 4 hours wait) is merged into trunk. If a feature requires more time, it is split into subtasks, each with its own short-lived branch.

According to TBD Documentation, 2024, short-lived branch rules: a branch is created from a fresh trunk (no older than 1 hour), is not synchronized with trunk via merge/rebase (if more than 4 hours have passed, a new branch is created), MR/PR is created immediately after the first commit (even if work is not complete — as Draft).

Pre-tested Commits: Commits with Guarantee

For Trunk-Based Development, the pre-tested commits technique is important: a developer runs the CI pipeline in their branch before committing, and only after a green status does the commit reach trunk. In GitLab, this is implemented through Merge Request pipelines with the “Merge when pipeline succeeds” option. In GitHub — through branch protection rules with Required status checks. This ensures that trunk never contains broken code.

• 1–2 days — maximum lifetime of a short-lived branch
• 1–3 commits — optimal change size
• 4 hours — maximum code review wait time
• Create MR immediately after the first commit, even in Draft status

Branch by Abstraction: Replacing Code Without Branching

Branch by Abstraction is a technique that allows replacing or significantly changing part of a system without creating a long-lived feature branch. Instead of branching in Git, the developer creates an abstraction (interface) under which both old and new implementations work. Gradually, all consumers are migrated to the new implementation, after which the old one is removed.

According to Branch by Abstraction, 2024, Branch by Abstraction stages: 1) create an abstraction for the component being replaced, 2) implement the new version under the abstraction, 3) switch consumers to the new implementation via configuration, 4) remove the old implementation. All steps are committed to trunk in small portions, each of which does not break CI/CD.

TBD vs Git Flow: Comparing Approaches

Trunk-Based Development and Git Flow are two opposing approaches to branch management. Git Flow uses long-lived branches and a strict hierarchy, TBD uses a single branch and short integration cycles. The choice between them depends on team size, release frequency, and level of CI/CD automation.

Common Mistakes When Implementing Trunk-Based Development

TBD mistakes are most often related to insufficient CI/CD or weak commit discipline. The first mistake is adopting TBD without CI, which breaks on the first failed commit. If trunk cannot be fixed within 15 minutes, the team loses trust in the process and returns to long-lived branches. The second is allowing long-lived branches “just for this feature,” which destroys the entire concept.

According to Paul Hammant, 2023, the third mistake is poor code modularity. Trunk-Based Development requires code to be split into independent modules. If changing one class breaks three other modules, developers cannot commit in small portions. The fourth is ignoring feature toggles: attempting to commit unfinished code without a flag breaks trunk for the entire team.

Trunk-Based Development in Mobile Development

Trunk-Based Development in mobile projects has peculiarities due to long build times (20–30 minutes for Android and iOS) and strict quality requirements. Google and Spotify use TBD in mobile development, applying short-lived branches with mandatory CI passing before merge. Feature toggles are managed through Firebase Remote Config or LaunchDarkly.

According to LaunchDarkly Docs, 2024, in mobile development, TBD provides an advantage: features are tested in trunk together with the rest of the code before the release date, reducing the risk of integration issues. If the CI pipeline takes more than 15 minutes, 1-day short-lived branches with automatic CI on every push are optimal. For Apple App Store and Google Play, TBD requires setting up staged rollouts via feature toggles.

Feature Flags as a Service: LaunchDarkly and Firebase

For managing feature toggles in TBD, platforms are used: LaunchDarkly (enterprise, full-featured), Firebase Remote Config (free for small projects), Split.io (open-source). They provide: targeted feature rollout by user percentage, A/B testing, usage monitoring, and automatic rollback on errors. In mobile projects, Firebase Remote Config is the most popular choice due to its integration with Firebase and a free tier of up to 1000 users.