At Salesken, I worked alongside product managers daily. The gap between what PMs needed to know and what they could actually see in the codebase was enormous — and it cost us weeks of misaligned sprints.
Elite engineering teams integrate code frequently. This is not a guess - it's in the Accelerate research. High-performing teams have higher integration frequency. They also have lower change failure rates.
This seems backwards. Wouldn't integrating more often break things more? No. The research is clear: frequent integration with strong CI is safer than infrequent integration with long-lived branches.
Trunk-based development (TBD) is the practice of having all engineers commit to a single main branch frequently (at least once per day) rather than maintaining long-lived feature branches.
How TBD Works
The mechanics:
- You have a main branch (trunk). Everyone integrates into it constantly.
- You work on small features or fixes. You complete them within a day.
- You submit a pull request with a few hours of work. Code review. Merge.
- The code is in production (or nearly production) immediately.
If you need to ship incomplete work (a feature that takes a week), you use feature flags. The code is merged. The feature is toggled off. When the feature is complete and tested, you flip the flag.
Short-lived branches (if you use them at all) are integrated within 24 hours. Long-lived branches are a smell that something is wrong.
Why TBD Correlates with High Performance
When you integrate infrequently, branches diverge. Service A's main branch is three weeks different from Service B's main branch. When they merge, there are conflicts. There are integration issues. Bugs appear. This is the merge hell that causes multi-day integrations where nothing else gets done.
When you integrate frequently, branches are never diverged. Merges are cheap. Conflicts are small and obvious.
When you integrate frequently with strong CI, you catch integration bugs immediately. Not three weeks later. Today. The person who caused it is still working on related code. They can fix it in 10 minutes.
Integration frequency is a leading indicator of team performance. Teams with daily integration ship faster and have fewer bugs than teams with weekly integration.
Cultural Requirements
TBD requires maturity in three areas:
CI is fast and reliable. If your CI takes 30 minutes and passes half the time, TBD breaks. Tests take too long to run. You commit code that breaks the build. People stop waiting for CI and just commit. The main branch is constantly broken.
Fix this first. Your CI should run in under 5 minutes. All the time. If it's slower, optimize or parallelize tests.
Tests cover integration. You're integrating frequently, so you need tests that catch integration problems quickly. Unit tests only test one service. Integration tests test multiple services talking to each other. You need both.
This is expensive. Accept that and do it anyway.
The team trusts reversibility. TBD means accepting that sometimes you'll merge something that breaks. You fix it by reverting. This requires a team culture where revert is normal and blameless. "We reverted your change" is not an accusation. It's "we're unblocking ourselves and we'll debug this offline."
Comparison with GitFlow and GitHub Flow
GitFlow is a branching model where you have develop and main branches, and features branch off develop. Releases are merged from develop to main. This is complex. It's useful if you have multiple versions in production simultaneously. Most companies don't. Don't use GitFlow.
GitHub Flow is: main branch, feature branches, PR, merge. This is better. It's simpler. But most teams using GitHub Flow use long-lived feature branches (weeks long). That's not GitHub Flow, that's just branching.
TBD is: main branch, small branches (hours long), merge within a day. No long-lived branches. Every engineer integrating every day.
The in my experience,: TBD > GitHub Flow > GitFlow in terms of integration frequency and performance.
Addressing Common Objections
"Our release cycle is monthly. We can't do TBD."
TBD is about integration frequency, not deployment frequency. You integrate to main every day. You deploy to production once a month. Feature flags control which features are visible. This works. You're decoupling integration from deployment.
"We need to maintain multiple versions."
Maintain the main branch. Tag releases from it. Patch releases branch from a tag. But all development happens on main. Everyone integrates there. You're not maintaining multiple development branches.
"Our code review process requires days of feedback."
That's not a code review process, that's a design process disguised as code review. Separate these. Design reviews happen before code is written. Code reviews check that code implements the design correctly. Code reviews should take hours, not days.
"Our services are too tightly coupled for TBD."
Decoupling is prerequisite work, not a blocker. But you do the decoupling work anyway (you should - tight coupling is a problem). Once you're decoupled, TBD works.
Honest Challenges
TBD is better than long-lived branches. But it requires maturity that not all teams have.
You need strong testing discipline. If you're not writing tests, TBD means your main branch is broken frequently. This is a real cost.
You need a team comfortable with small increments. Some teams like to see their feature completely finished before integrating. TBD requires thinking in small increments and integrating early.
You need good feature flag infrastructure. Feature flags are not free. They add complexity. They can have bugs. You need a system for managing them. The cost is worth it, but it's real.
You need trust in the team. TBD requires trusting that people will write tests, review carefully, and revert quickly if something breaks. Some teams aren't there yet.
These aren't reasons to avoid TBD. They're reasons to address them. Strong CI, testing discipline, and team trust are not TBD prerequisites - they're engineering fundamentals that make you better across the board.
Patterns That Make TBD Work
Commit small. One feature, one commit. One bug fix, one commit. Commits that are easy to review and easy to revert. Don't bundle three days of work into one huge commit.
Review fast. Code review within a day. If review is taking days, you're blocking integration.
Test before integrating. Your tests pass locally. CI passes. Then you merge. Obvious but important.
Feature flags for incomplete work. Incomplete features are merged with flags off. This lets you integrate without shipping incomplete features.
Automated deployment. When you merge, it goes through the pipeline toward production. Automated checks verify it's safe. This makes frequent integration practical.
Connecting to Codebase Intelligence
Here's where Glue helps. TBD is the goal. Are you actually doing it?
Glue lets you ask: "Show me all the git branches. Which ones have been open for more than two days? Are they feature branches waiting for code review? Are they waiting for merge conflicts to be resolved?" This shows where TBD is breaking down.
Or: "Show me the commit frequency per engineer. Are people committing multiple times per day or once per week?" Commit frequency is a signal of how well TBD is working.
Or: "Show me branches that diverged from main by more than 1000 commits. Those are multi-week branches." That's a sign TBD isn't happening.
Or: "Show me the code review time. What's the median time from PR open to merge? What's the 95th percentile?" If PRs are sitting for days, TBD is blocked.
Codebase intelligence shows the gap between TBD as a goal and TBD in practice.
Trunk-Based Development in 60 Seconds TL;DR
TBD means daily integration to main. Short-lived branches (hours long), not long-lived branches (weeks long). Correlates with elite team performance. Requires: fast reliable CI (under 5 minutes), strong testing (unit and integration), team trust in reversibility. Use feature flags for incomplete work. Decouples integration (daily) from deployment (monthly). Objection: "we need long branches for big features" - use flags. TBD is not magic - it requires testing discipline and team maturity.
Frequently Asked Questions
Q: How do you handle large features that take weeks to build?
A: Break them into smaller completable pieces. Integrate each piece with flags off. Or build the feature on main with flags off, and enable the flag when complete. You're integrating code continuously, even if the feature itself is incomplete.
Q: What if someone breaks the build?
A: Revert their change. Fix offline. This should take 10 minutes. If it takes hours, your CI or testing isn't good enough. That's a separate problem to address.
Q: Isn't trunk-based development risky?
A: Less risky than long-lived branches diverging for weeks and then integrating with a cascade of merge conflicts and integration bugs. TBD finds problems fast when they're cheap to fix.
Related Reading
- AI for Product Management: The Difference Between Typing Faster and Thinking Better
- The Product Manager's Guide to Understanding Your Codebase
- AI Product Discovery: Why What You Build Next Should Not Be a Guess
- Cursor for Product Managers: The Next AI Shift Nobody Is Talking About
- Product OS: Why Every Engineering Team Needs an Operating System
- Software Productivity: What It Really Means and How to Measure It