Trunk-Based Development vs Gitflow: Why TBD Won at Scale

When your engineering organisation grows from a single team working on a monolith to multiple domain-driven teams, your branching strategy needs to evolve too. At Cashrewards, we lived through this transformation, moving from Gitflow to Trunk-Based Development (TBD) as we scaled. Here's why TBD became our go-to approach and how it changed our development workflow.

Understanding the Two Approaches

Gitflow: The Traditional Branching Model

Gitflow, introduced by Vincent Driessen in 2010, follows a structured branching model with multiple long-lived branches:

• Main/Master: Production-ready code
• Develop: Integration branch for features
• Feature branches: Individual feature development
• Release branches: Preparing releases
• Hotfix branches: Critical production fixes

# Typical Gitflow workflow
git checkout develop
git checkout -b feature/new-payment-method
# ... develop feature
git checkout develop
git merge feature/new-payment-method
git checkout -b release/v2.1.0
# ... prepare release
git checkout main
git merge release/v2.1.0

Gitflow Strengths:

• Clear separation of concerns
• Structured release management
• Easy to grasp for new developers
• Supports multiple release versions

Gitflow Pain Points:

• Complex merge conflicts
• Slower integration feedback
• Context switching overhead
• Release bottlenecks

Trunk-Based Development: The Streamlined Approach

TBD is a branching model where developers collaborate on code in a single branch called "trunk" (usually main or master), with minimal branching:

• Main/Trunk: Single source of truth
• Short-lived feature branches: Optional, merged within hours/days
• Feature flags: Control feature rollouts
• Continuous integration: Frequent commits to trunk

# Typical TBD workflow
git checkout main
git pull origin main
git checkout -b feature/payment-optimization
# ... small, focused changes
git checkout main
git merge feature/payment-optimization
git push origin main
# Deploy immediately or via feature flags

TBD Strengths:

• Reduced integration complexity
• Faster feedback loops
• Simplified workflow
• Enables continuous deployment
• Reduces merge conflicts

TBD Challenges:

• Requires mature CI/CD practices
• Needs feature flag management
• Demands high code quality standards
• Requires cultural shift

The Cashrewards Journey: From Monolith to Microservices

The Gitflow Era

Initially, Cashrewards operated as a single engineering team working on a monolithic application. When I joined as one of 8 engineers during the early startup phase, Gitflow served us well. Through the IPO journey and beyond, I witnessed firsthand how we grew the engineering team to 40+ engineers organized into domain-focused squads.

Single Team → Monolith → Gitflow
- Clear release cycles
- Coordinated deployments
- Predictable workflow

Our release process looked like this:

1. Features developed in isolation on feature branches
2. Weekly integration into develop branch
3. Bi-weekly releases via release branches
4. Coordinated deployment windows

The Scaling Challenge

As Cashrewards grew, we hit the usual scaling problems:

• Team Growth: From 8 to 40+ engineers
• Domain Complexity: Payment processing, rewards, merchant partnerships, user engagement
• Release Coordination: Multiple teams waiting for shared release windows
• Context Switching: Developers juggling multiple long-lived branches

The warning signs became obvious:

• Integration conflicts increased exponentially
• Release cycles slowed from bi-weekly to monthly
• Hotfixes became complex multi-branch operations
• Developer productivity tanked due to merge overhead

The Domain-Driven Transformation

We restructured into domain-driven teams:

• Transaction Team: Payment processing, fraud detection
• Accounts Team: User management, authentication
• Offers Team: Deal curation, merchant campaigns
• Engage Squad: User acquisition, engagement features
• Retail Media Squad: Advertising platform, brand partnerships
• Partnership Squad: Merchant integrations, API partnerships

Each team needed:

• Independent deployment capability
• Reduced inter-team dependencies
• Faster feedback cycles
• Autonomous decision-making

Why TBD Became Our Solution

1. Reduced Integration Complexity

Before (Gitflow):

# Team A develops feature over 2 weeks
git checkout -b feature/loyalty-program
# ... 2 weeks of development
# Integration day: merge conflicts with 3 other features
git checkout develop
git merge feature/loyalty-program
# Conflicts with transaction-refactor, user-profiles, offer-api

After (TBD):

# Daily small commits to main
git checkout -b small-feature/loyalty-points-calculation
# ... 4 hours of focused development
git checkout main
git merge small-feature/loyalty-points-calculation
# Minimal conflicts, immediate integration

2. Faster Deployment Velocity

With TBD, each team could deploy independently:

Deployment Frequency:
Gitflow Era: 2 deployments/month (coordinated)
TBD Era: 50+ deployments/month (autonomous)

3. Feature Flag-Driven Development

TBD enabled us to decouple deployment from release:

// Feature flag example
if (featureFlags.isEnabled('new-cashback-calculation', user)) {
  return calculateCashbackV2(transaction);
} else {
  return calculateCashbackV1(transaction);
}

Benefits:

• Deploy code safely to production
• Test features with subset of users
• Instant rollback capability
• A/B testing infrastructure

4. Improved Team Autonomy

Each domain team gained:

• Independent release cycles
• Reduced coordination overhead
• Faster iteration on domain-specific features
• Clear ownership boundaries

Implementation Strategy at Cashrewards

Phase 1: Foundation Building (Month 1-2)

1. CI/CD Pipeline Enhancement

   # GitHub Actions example
   name: Continuous Integration
   on:
     push:
       branches: [main]
     pull_request:
       branches: [main]
   
   jobs:
     test:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - name: Run Tests
           run: npm test
         - name: Deploy to Staging
           if: github.ref == 'refs/heads/main'
           run: npm run deploy:staging

2. Feature Flag Infrastructure

   • Implemented Unleash for feature management (later migrated to Optimizely)
   • Created team-specific flag namespaces
   • Established flag lifecycle management

3. Enhanced Monitoring and Observability

• Beefed up error tracking (Sentry)
• Performance monitoring (DataDog)
• Business metrics dashboards

Phase 2: Process Transition (Month 3-4)

1. Branch Policy Changes

   # New branch protection rules
   - Require pull request reviews (2 reviewers)
   - Require status checks to pass
   - Require branches to be up to date
   - Maximum branch age: 2 days

2. Developer Training

   • TBD workshops for all teams
   • Pair programming sessions
   • Code review best practices
   • Feature flag management training

3. Gradual Migration

   • Started with least risky services
   • One team at a time adoption
   • Parallel Gitflow support during transition

Phase 3: Full Adoption (Month 5-6)

1. Team Autonomy Implementation

   • Independent deployment pipelines per domain
   • Team-specific monitoring dashboards
   • Automated rollback mechanisms

2. Cultural Reinforcement

   • Daily deployment targets
   • Small batch size metrics
   • Integration frequency tracking

Measuring Success: TBD vs Gitflow Metrics

Development Velocity

Metric                 | Gitflow Era | TBD Era     | Improvement
-----------------------|-------------|-------------|------------
Lead Time              | 2-3 weeks   | 2-3 days    | 83% faster
Deployment Frequency   | Bi-weekly   | Daily       | 14x increase
Mean Time to Recovery  | 4-6 hours   | 15-30 min   | 88% faster
Change Failure Rate    | 15%         | 5%          | 67% reduction

Team Productivity

• Code Review Time: 2 days → 4 hours
• Integration Conflicts: Weekly → Rare
• Context Switching: High → Minimal
• Developer Satisfaction: 6/10 → 8.5/10

Business Impact

• Feature Time-to-Market: 4 weeks → 1 week
• Experiment Velocity: 2/month → 12/month
• Hotfix Resolution: 6 hours → 30 minutes
• Customer Issue Response: Same day → Real-time

Best Practices for TBD Success

1. Commit Hygiene

# Good TBD commits
git commit -m "feat: add cashback calculation for grocery category"
git commit -m "fix: handle edge case in payment validation"
git commit -m "refactor: extract merchant API client"

# Each commit should:
- Be deployable
- Include tests
- Have clear intent
- Be reviewable in < 10 minutes

2. Feature Flag Strategy

// Gradual rollout pattern
const featureConfig = {
  name: 'enhanced-search',
  rollout: {
    percentage: 25,
    userTypes: ['premium'],
    geoTargets: ['AU', 'NZ'],
  },
};

3. Automated Quality Gates

# Quality pipeline
quality_gates:
  - unit_tests: >95% coverage
  - integration_tests: all_passing
  - security_scan: no_high_vulnerabilities
  - performance_test: <500ms_p95
  - accessibility_test: wcag_aa_compliant

4. Monitoring and Alerting

// Business metrics monitoring
const metrics = {
  deploymentFrequency: 'daily',
  leadTime: '< 3 days',
  mttr: '< 30 minutes',
  changeFailureRate: '< 5%',
};

Common Pitfalls and How We Avoided Them

1. "Big Bang" Migration

Mistake: Switching all teams simultaneously Solution: Gradual team-by-team adoption with parallel support

2. Insufficient Automation

Mistake: Manual testing and deployment processes Solution: Invested heavily in CI/CD before switching

3. Poor Feature Flag Hygiene

Mistake: Accumulating technical debt from old flags Solution: Automated flag cleanup and lifecycle management

4. Inadequate Monitoring

Mistake: Reduced visibility into system health Solution: Enhanced observability before migration

When to Choose TBD vs Gitflow

Choose TBD When:

• Teams need independent deployment capability
• High deployment frequency is required
• Mature CI/CD practices exist
• Feature flag infrastructure is available
• Team autonomy is prioritized

Choose Gitflow When:

• Coordinated releases are necessary
• Multiple supported versions exist
• Limited CI/CD maturity
• Regulatory compliance requires formal release processes
• Team is new to modern development practices

The Road Ahead

TBD at Cashrewards has enabled:

• Faster Innovation: Rapid experimentation and iteration
• Improved Reliability: Smaller, safer changes
• Team Empowerment: Autonomous decision-making
• Business Agility: Quick response to market opportunities

The transition wasn't just about changing our branching strategy - it was about embracing a culture of continuous improvement, team autonomy, and customer-centric development.

What We Learnt

1. Context Matters: The best branching strategy depends on your team structure and business needs
2. Infrastructure First: Get your automation sorted before changing processes
3. Cultural Change: TBD requires shifts in mindset, not just tooling
4. Measure Everything: Track metrics to validate the transition actually worked
5. Start Small: Gradual adoption reduces risk and builds confidence

Our journey from Gitflow to TBD at Cashrewards shows that the right development workflow can unlock massive improvements in both developer experience and business outcomes. When scaling engineering organisations, the processes that got you here might become bottlenecks - and that's exactly when it's time to evolve.

Have you been through similar scaling challenges in your organisation? What branching strategies have worked best for your team structure? Would love to hear about your experiences.