Skip to content

Trunk-Based Development: Faster Delivery with Less Complexity

DodaTech Updated 2026-06-22 5 min read

In this tutorial, you'll learn about Trunk. We cover key concepts, practical examples, and best practices.

Trunk-based development has developers commit directly to a single shared branch with feature flags hiding incomplete work, enabling continuous delivery.

In this tutorial, you'll learn trunk-based development — a Git branching strategy where developers integrate small changes into a shared main branch several times a day. This approach reduces merge complexity, enables continuous delivery, and is used by high-performing teams at Google, Netflix, and Facebook. By the end, you'll implement trunk-based development with feature flags and automated CI.

flowchart TD
  A[Start: trunk-based dev] --> B[Create short-lived branch]
  B --> C[Make small changes]
  C --> D[Run tests locally]
  D --> E[Commit & push]
  E --> F[CI pipeline runs]
  F --> G{All tests pass?}
  G -->|No| H[Fix immediately]
  H --> E
  G -->|Yes| I[Merge to main]
  I --> J[Deploy to production]
  J --> K[Monitor & repeat]

Core Principles

Principle Description Practice
Short-lived branches Branches last hours, not days Maximum 1 day before merging
Feature flags Hide incomplete features Toggle in code or config
Continuous integration Every commit triggers tests CI must run in under 10 minutes
Small commits Each commit is a logical unit Aim for 1-2 files per commit
Peer review Quick reviews for small changes Review within 1-2 hours
Automated deployment Ship as soon as merged CI/CD deploys automatically

Feature Flags for Incomplete Work

Feature flags let you merge incomplete features without affecting users:

# config.py
FEATURE_FLAGS = {
    "new_checkout": False,
    "dark_mode": True,
}

# app.py
if FEATURE_FLAGS["new_checkout"]:
    show_new_checkout()
else:
    show_old_checkout()

Setting Up Trunk-Based Development

# Clone main branch
git clone https://github.com/team/project.git
git checkout -b add-dark-mode

# Make small changes
echo "dark-mode: true" >}} config.yml
git add config.yml
git commit -m "feat(ui): add dark mode theme toggle"

# Run tests
npm test

# Push
git push -u origin add-dark-mode

# Create PR, get quick review, merge
# Delete branch after merge

CI Requirements for Trunk-Based

Trunk-based development requires fast, reliable CI:

name: Trunk CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

CI must complete in under 10 minutes. If it takes longer, optimize tests or parallelize.

Deployment Strategy

Deploy directly from main after CI passes:

deploy:
  needs: ci
  runs-on: ubuntu-latest
  if: github.ref == 'refs/heads/main'
  steps:
    - uses: actions/checkout@v4
    - name: Deploy
      run: ./deploy.sh

For zero-downtime deployment, use blue-green or canary releases.

Trunk-Based vs Other Strategies

Aspect Trunk-Based Git Flow GitHub Flow
Branch lifetime Hours Days-weeks Hours-days
Number of permanent branches 1 (main) 2 (main, develop) 1 (main)
Feature flags Required Not required Optional
Deployment frequency Multiple times/day Per release Per merged PR
CI speed requirement Fast (under 10 min) Moderate Moderate
Team size 5-20 10+ 3-10
Complexity Low High Low

Common Errors

Error Cause Fix
Broken main branch CI not catching issues Improve test coverage and CI speed
Feature flag accumulation Old flags never removed Schedule regular flag cleanup
CI takes too long Tests not optimized Parallelize tests, remove slow tests
Peer review bottleneck Reviews take hours Enforce small PRs and quick reviews
Developers skip feature flags Incomplete code merged Education and code review enforcement
Merge conflicts despite short branches Poor coordination Communicate overlapping changes
Deployment failures Insufficient staging Add staging environment or canary deploys
Feature flags in production cause issues Unused code paths Remove flags as soon as feature is stable

Practice Questions

What is trunk-based development?

Trunk-based development is a Git branching strategy where all developers integrate their changes into a single shared branch (the trunk or main) multiple times per day. Branches are short-lived (under a day), and incomplete work is hidden behind feature flags. This enables continuous integration and deployment.

Why are feature flags essential for trunk-based development?

Feature flags let developers merge incomplete features to main without exposing them to users. This removes the need for long-lived feature branches. The feature can be toggled on/off via config, allowing safe deployment of main at any time regardless of feature readiness.

How short should branches be in trunk-based development?

Branches should last less than one day, ideally a few hours. Longer branches defeat the purpose of trunk-based development — they accumulate changes, create merge conflicts, and delay integration. If a branch lasts more than a day, break the work into smaller pieces.

What happens if someone breaks the main branch?

Fixing a broken main branch is the highest priority. The developer who broke it stops whatever they're doing and fixes it immediately. If the fix takes more than a few minutes, revert the broken commit and fix locally before re-merging. This discipline keeps the trunk always deployable.

Is trunk-based development suitable for mobile apps?

Yes, but with modifications. Mobile apps go through app store review, so you can't deploy instantly. Use trunk-based development for the codebase but create release branches from main when submitting for review. Continue developing on main and cherry-pick fixes into the release branch

Challenge

Set up a trunk-based development workflow for a JavaScript project. Create feature flags for two features (dark mode and new checkout). Make three small commits to main in one day, each with passing CI. Use feature flags so one feature is hidden in production. Write the CI/CD pipeline that deploys automatically on main commits. Remove the flag for the stable feature after one week.

Real-World Task

Migrate a team from Git Flow (with 2-week release cycles) to trunk-based development. Plan the transition: (1) Set up feature flag infrastructure, (2) Reduce CI pipeline time from 45 minutes to under 10, (3) Train team on short-lived branches, (4) Implement automated deployment from main, (5) Schedule removal of old flags after one month. This migration approach was used at DodaTech to accelerate delivery of Durga Antivirus Pro updates from bi-weekly to multiple times per day.


Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro