Trunk-Based Development (TBD) is a version control strategy where all developers commit code changes directly to a single shared branch (the “trunk” or “main” branch) instead of using long-lived feature branches. This approach minimizes merge conflicts, accelerates integration, and enables continuous delivery by keeping the codebase in a constantly deployable state.
Table of contents
Open Table of contents
- Understanding Trunk-Based Development
- Key Characteristics of Trunk-Based Development
- Benefits of Trunk-Based Development
- Trunk-Based Development vs. Feature Branching
- How to Implement Trunk-Based Development
- Common Challenges and Solutions
- Best Practices for Success
- Tools and Technologies
- Real-World Examples
- Frequently Asked Questions
- What is trunk-based development?
- Why is trunk-based development a recommended practice for continuous integration?
- What is the difference between trunk-based development and Git Flow?
- How does trunk-based development work with feature flags?
- Can small teams use trunk-based development?
- What is the recommended branch lifetime in trunk-based development?
- How do you handle releases in trunk-based development?
- What happens if someone breaks the trunk/main branch?
- Does trunk-based development work without automated testing?
- How do code reviews work in trunk-based development?
- Considerations and Prerequisites
- Conclusion
- Additional Resources
Understanding Trunk-Based Development
Trunk-Based Development is a source control branching model where developers collaborate on code within a single branch, commonly called the “trunk,” “main,” or “master” branch. This approach discourages the creation of long-lived development branches, aiming to prevent complex merge conflicts and maintain a stable codebase. TBD is closely tied to practices like Continuous Integration (CI) and Continuous Delivery (CD), enabling teams to release code frequently and reliably.
Why Choose Trunk-Based Development
Modern software teams face increasing pressure to deliver features rapidly while maintaining code quality. Traditional branching strategies with long-lived feature branches often lead to painful merge conflicts, delayed integration, and slow release cycles. Trunk-Based Development addresses these challenges by promoting frequent integration and maintaining a single source of truth.
Key Characteristics of Trunk-Based Development
Continuous Integration
Developers commit code changes directly to the trunk multiple times a day, ensuring that the codebase is always in a releasable state. This practice is a cornerstone of Continuous Integration and facilitates Continuous Delivery.
Key practices include:
- Committing small, incremental changes frequently (multiple times per day)
- Running automated tests before each commit
- Fixing broken builds immediately (within 10 minutes)
- Maintaining the trunk in a deployable state at all times
Short-Lived Feature Branches
In larger teams, short-lived branches may be used for code reviews and build verification before merging into the trunk. These branches are typically the work of a single developer and exist for a brief period to minimize integration issues.
Best practices for short-lived branches:
- Lifetime: 24-48 hours maximum
- Scope: Single feature or bug fix
- Process: Create, review, merge, delete
- Frequency: Merge to trunk at least once per day
Feature Flags and Branch by Abstraction
To manage in-progress features without disrupting the main codebase, TBD employs techniques like feature flags and branch by abstraction. These methods allow incomplete features to be merged into the trunk safely and toggled on or off as needed. This approach allows teams to experiment with features and make incremental changes without delaying the main development flow.
Feature Flags enable:
- Gradual feature rollouts
- A/B testing in production
- Quick feature rollback without code deployment
- Separating deployment from release
Branch by Abstraction involves:
- Creating an abstraction layer for new functionality
- Gradually migrating old code to new implementation
- Removing the abstraction once migration is complete
Benefits of Trunk-Based Development
Reduced Merge Conflicts
By avoiding long-lived branches, TBD minimizes the risk of significant merge conflicts, leading to a more streamlined development process. Regular commits to the trunk allow changes to be integrated and tested in smaller, more manageable chunks.
Conflict reduction strategies:
- Small, frequent commits reduce change size
- Immediate conflict resolution while context is fresh
- Automated merge conflict detection
- Pair programming for complex changes
Enhanced Team Collaboration
With all developers working on a single branch, there’s greater visibility into ongoing changes, fostering improved collaboration and communication within the team. Since everyone is working on the same branch, feedback and code review are more immediate, enhancing team cohesion.
Collaboration benefits:
- Shared understanding of codebase state
- Immediate visibility of changes
- Faster code review cycles
- Reduced knowledge silos
Accelerated Release Cycles
The emphasis on frequent commits and continuous integration ensures that the codebase is always in a deployable state, enabling faster and more reliable release cycles. By maintaining a stable trunk, teams can release updates frequently with confidence, reducing the risk of bugs and regressions.
Release advantages:
- Deploy to production multiple times per day
- Reduced time between feature completion and user delivery
- Lower risk per deployment (smaller change sets)
- Faster customer feedback loops
Scalability and Flexibility
Even large teams, like those at Google and Facebook, have successfully implemented Trunk-Based Development at scale. The model scales by using techniques like feature flags and branch by abstraction to manage parallel work without disrupting the main development stream. This allows for consistent development practices regardless of team size.
Scaling considerations:
- Google: 25,000+ developers, single monorepo
- Facebook: Thousands of commits per day to main branch
- Microsoft: Successful TBD adoption across teams
- Automated tooling essential for large-scale TBD
Trunk-Based Development vs. Feature Branching
| Aspect | Trunk-Based Development | Feature Branching (Git Flow) |
|---|---|---|
| Branch Lifetime | Hours to 1-2 days | Days to weeks |
| Integration Frequency | Multiple times per day | Periodically or at feature completion |
| Merge Conflicts | Minimal, resolved immediately | Frequent, complex resolutions |
| Code Review | Before trunk commit | Before merge to main |
| Release Cadence | Continuous, multiple per day | Scheduled, less frequent |
| Team Size | Scales to any size | Better for smaller teams |
| CI/CD Integration | Essential, tightly coupled | Optional, often decoupled |
| Feature Management | Feature flags | Separate branches |
| Risk Profile | Low risk, small changes | Higher risk, larger merges |
| Learning Curve | Moderate, requires discipline | Low, familiar to most devs |
How to Implement Trunk-Based Development
Step 1: Establish Continuous Integration
Set up automated build and test pipelines that run on every commit. Ensure builds complete in under 10 minutes to maintain fast feedback loops.
CI requirements:
- Automated unit tests (target: <5 minute execution)
- Integration tests (target: <10 minute execution)
- Code quality checks (linting, static analysis)
- Build success notifications
Step 2: Implement Feature Flags
Deploy a feature flag system to control feature visibility in production without requiring code changes.
Popular feature flag tools:
- LaunchDarkly
- Split.io
- Unleash
- Custom solutions (environment variables, configuration files)
Step 3: Define Branch Policies
Establish clear rules for when and how to create branches.
Example policy:
- Default: Commit directly to trunk
- For code review: Create branch, merge within 24 hours
- Emergency hotfixes: Trunk-first, then backport if needed
Step 4: Train Your Team
Ensure all team members understand TBD principles and practices.
Training topics:
- Small commit practices
- Feature flag usage
- Trunk stability responsibilities
- Rollback procedures
Step 5: Start Small
Begin with a pilot project or team before organization-wide rollout.
Pilot success criteria:
- 90% of commits directly to trunk
- Build stability >95%
- Reduced merge conflict time
- Faster feature delivery
Common Challenges and Solutions
Challenge: “Our features take weeks to develop”
Solution: Use feature flags to merge incomplete code to trunk while keeping features hidden from users.
Challenge: “What about code review?”
Solution: Implement pre-commit hooks, pair programming, or very short-lived review branches (<24 hours).
Challenge: “Our builds are too slow”
Solution: Optimize test suites, implement test parallelization, or use incremental builds.
Challenge: “We need stable release branches”
Solution: Tag releases from trunk, use feature flags for stability, create release branches only for long-term support.
Challenge: “Junior developers might break trunk”
Solution: Implement robust automated testing, enable revert-on-red policies, provide mentorship and pair programming.
Best Practices for Success
1. Maintain Trunk Stability
- Red builds are emergencies: Fix within 10 minutes or revert
- Automated quality gates: Prevent bad commits from reaching trunk
- Monitoring and alerts: Immediate notification of build failures
2. Commit Frequently
- Target: 2-5 commits per developer per day
- Size: Each commit should be independently deployable
- Quality: Every commit passes all tests
3. Invest in Automation
- Testing: Comprehensive automated test coverage (target: >80%)
- Deployment: One-click or automated deployment process
- Monitoring: Real-time production health visibility
4. Use Feature Flags Wisely
- Temporary flags: Remove after feature is stable
- Technical debt: Track and clean up old flags
- Documentation: Maintain flag inventory
5. Practice Continuous Improvement
- Metrics: Track merge time, build stability, deployment frequency
- Retrospectives: Regular team discussions on TBD effectiveness
- Adaptation: Adjust practices based on team feedback
Tools and Technologies
Version Control Systems
- Git: Most popular, works well with TBD
- Mercurial: Also supports trunk-based workflows
- Perforce: Used by large organizations (gaming, enterprise)
CI/CD Platforms
- Jenkins: Flexible, widely adopted
- GitHub Actions: Integrated with GitHub
- GitLab CI: Integrated with GitLab
- CircleCI: Cloud-based, easy setup
- Travis CI: Popular for open source
Feature Flag Services
- LaunchDarkly: Enterprise-grade feature management
- Split.io: Feature experimentation platform
- Unleash: Open-source alternative
- ConfigCat: Lightweight solution
Monitoring and Observability
- Datadog: Comprehensive monitoring
- New Relic: Application performance monitoring
- Prometheus + Grafana: Open-source monitoring stack
Real-World Examples
Google has used Trunk-Based Development for decades, with over 25,000 developers committing to a single monorepo. Their success relies heavily on:
- Extensive automated testing infrastructure
- Fast build systems (Bazel)
- Code review culture (Gerrit)
- Sophisticated tooling for large-scale refactoring
Facebook deploys to production twice daily using trunk-based workflows:
- Main branch is always deployable
- Feature flags control feature rollouts
- Automated testing runs on every commit
- “Move fast” culture supported by TBD
Microsoft
Microsoft has transitioned many teams to Trunk-Based Development:
- Windows team uses TBD with feature flags
- Azure services practice continuous deployment
- Developer productivity increased significantly
- Reduced integration pain compared to previous workflows
Frequently Asked Questions
What is trunk-based development?
Trunk-Based Development is a version control practice where developers merge small, frequent updates to a single branch called “trunk” or “main,” avoiding long-lived feature branches to enable continuous integration and faster release cycles.
Why is trunk-based development a recommended practice for continuous integration?
Trunk-based development is recommended for CI because it ensures code is integrated frequently (multiple times per day), preventing integration hell, enabling fast feedback, and keeping the codebase in a constantly deployable state—all essential for effective continuous integration.
What is the difference between trunk-based development and Git Flow?
The main differences are:
- TBD: Single long-lived branch (trunk), short-lived feature branches (<2 days), continuous integration
- Git Flow: Multiple long-lived branches (develop, main, release), feature branches last days/weeks, periodic integration
How does trunk-based development work with feature flags?
Feature flags allow developers to merge incomplete features to trunk while keeping them hidden from users. Features are wrapped in conditional statements that check flag status, enabling deployment without release and gradual rollouts.
Can small teams use trunk-based development?
Yes! Small teams (2-10 developers) can often commit directly to trunk without branches. The smaller the team, the easier TBD becomes. Start with direct commits and add short-lived branches only when needed for code review.
What is the recommended branch lifetime in trunk-based development?
The recommended maximum lifetime for feature branches in TBD is 24-48 hours. Ideally, branches should be merged within one day to minimize integration issues and maintain the benefits of frequent integration.
How do you handle releases in trunk-based development?
Releases are handled by:
- Tagging: Create release tags from trunk
- Feature flags: Control feature visibility in production
- Release branches: Only for long-term support (optional)
- Continuous deployment: Many teams deploy every trunk commit
What happens if someone breaks the trunk/main branch?
When trunk is broken:
- Immediate notification: Automated alerts to team
- Fast fix: Developer has 10 minutes to fix
- Revert policy: If not fixed quickly, revert the commit
- Post-mortem: Understand why tests didn’t catch the issue
Does trunk-based development work without automated testing?
TBD is extremely risky without comprehensive automated testing. The lack of testing would result in frequent trunk breaks and unreliable deployments. Automated testing is a prerequisite for successful TBD implementation.
How do code reviews work in trunk-based development?
Code reviews in TBD can be done via:
- Pre-commit reviews: Review before merging to trunk (preferred)
- Pair programming: Real-time review during development
- Post-commit reviews: Review after merging (less common)
- Short-lived review branches: Create, review, merge within 24 hours
Considerations and Prerequisites
While TBD offers numerous advantages, it requires a disciplined approach to ensure build stability. Teams must implement robust automated testing and establish clear protocols for committing code to maintain the integrity of the main branch.
Prerequisites for success:
- Automated testing: Comprehensive unit and integration tests
- CI/CD infrastructure: Fast, reliable build pipelines
- Team discipline: Commitment to small, frequent commits
- Feature flag system: Mechanism to hide incomplete features
- Monitoring: Production health visibility
- Culture: Trust and shared responsibility for trunk stability
To successfully adopt TBD, teams must embrace the culture of frequent integration, fast feedback loops, and a high level of trust in the automated testing processes.
Conclusion
Trunk-Based Development is a powerful approach to version control that enables fast, reliable software delivery. By maintaining a single source of truth, integrating frequently, and leveraging modern techniques like feature flags, teams can reduce merge conflicts, accelerate release cycles, and scale effectively.
Key takeaways:
- TBD prioritizes frequent integration over branch isolation
- Feature flags enable merging incomplete code safely
- Automated testing is non-negotiable for TBD success
- Teams of all sizes can benefit from TBD practices
- Start small, measure results, and iterate
Additional Resources
For a more comprehensive exploration of Trunk-Based Development, including its history, best practices, and implementation strategies, visit:
- trunkbaseddevelopment.com - Official TBD reference
- Google’s Engineering Practices - Code review guidelines
- Feature Flag Best Practices - Managing feature flags effectively
- Continuous Integration - Martin Fowler’s seminal article
Last Updated: December 26, 2025
Reading Time: ~15 minutes
Difficulty Level: Intermediate
