If you’ve followed the first two parts of this series, you know the hard truth: most teams aren’t actually doing Trunk-Based Development. They are doing “Short-lived Feature Branching” with better branding. We’ve talked about why your PRs are still too big and why the 6-month pull request is a parallel universe that kills delivery.
But how do you actually fix it? Knowing small PRs are better is easy. Changing a team’s habits is the hard part.
This is the practical roadmap for moving from long-lived branches to real trunk-based flow.
Previous posts about Trunk-Based Development: Pt. 2 –https://codecraftdiary.com/2026/04/29/trunk-based-development-your-pull-requests-are-still-too-big/
Phase 1: Fixing the Foundation (The Infrastructure)
You cannot do trunk-based development with slow pipelines. If your CI/CD suite is a bottleneck, your developers will naturally revert to batching work to “save time”.
1. The 10-Minute Rule for CI
In 2026, speed is a requirement, not a luxury. If your CI takes 20 minutes, there is friction; if it takes 60 minutes, people stop merging frequently.
- Target: Aim for CI under 10 minutes.
- Action: Parallelize your test suites. If a test is flaky, don’t ignore it—fix it or delete it. A flaky test suite is a debt that destroys the confidence needed for frequent merges.
2. Radical Observability
To merge to main multiple times a day safely, you need to know exactly what is happening in production.
- Action: Implement real-time logging and alerting. If you merge a small change and the error rate spikes, you should know within seconds, not after a customer support ticket arrives.
Phase 2: Mastering the Tools of “Incomplete” Work
The biggest fear in TBD is merging work that isn’t “done”. To overcome this, you must decouple deployment from release.
3. Feature Flags as a Standard
Feature flags are the missing piece for most teams. They allow you to merge partial work and control exposure without waiting for the entire feature to be polished.
- The Strategy: Wrap new logic in a toggle. This lets the code live in the main branch, deployed to production but hidden from users until it’s ready.
- The Rule: A feature flag must exist from the start, not as an afterthought.
4. Branch by Abstraction for Large Changes
When you are doing a complete architectural overhaul, do not create a “v2-architecture” Git branch. That is a recipe for a merge nightmare.
- The Strategy: Keep both the old and new architectures in the main branch simultaneously.
- The Execution: Use an abstraction layer (an interface or wrapper) to toggle between the old and new logic. Run “dark launches” where the new code executes, but you ignore the results or simply compare them against the old version to gain confidence.
Phase 3: Rewiring the Process (Small PRs)
Small pull requests are the backbone of TBD. A large PR is a cognitive nightmare that leads to shallow reviews and delayed deployments.
5. Enforce Hard PR Size Limits
Don’t make small PRs a suggestion; make them a constraint.
- The Rule: Set a soft limit of ~300 lines and a hard limit of ~400–500 lines per PR.
- The Logic: Constraints force better behavior. If a task is too big, it forces the developer to think about how to slice it vertically.
6. Vertical vs. Horizontal Slicing
Stop splitting work by “Backend PR,” “Database PR,” and “Frontend PR”. This creates artificial dependencies and forces you to wait until all are done before merging.
- The Strategy: Slice vertically. One PR should deliver a minimal end-to-end functionality (even if hidden by a flag), followed by another PR that extends that behavior.
Phase 4: The Cultural Shift (The Hard Part)
Trunk-based development is 10% tooling and 90% discipline.
7. Optimize for Review Speed, Not Just Quality
If reviews take days, developers will batch work to avoid the “waiting tax”.
- Expectation: A PR should be reviewed within a few hours, not days.
- Technique: If a PR is small (under 300 – 400 lines), it takes 15 minutes to review. If it’s still stuck, do live reviews or pair programming to clear the logjam.
8. Accept “Ugly but Correct”
Flow matters more than perfection.
- The Mindset: It is better to merge a small, slightly imperfect (but safe) change today than a “perfect” massive change next week. You can refactor and improve incrementally once the code is integrated -> but don’t forget to refactor.
Phase 5: The Cleanup and AI Reality
AI-assisted coding is generating more code than ever. If you don’t have small changes and fast integration, your workflow will collapse under the sheer volume of AI-generated changes.
9. The Non-Optional Cleanup
Feature flags and abstractions are great, but they create technical debt if left forever.
- The Rule: Once a rollout is 100% successful, deleting the old code and the flag is part of the original task, not a “nice-to-have” for later.
10. Track Your Behavior (Metrics)
Stop guessing if you are doing TBD. Measure it.
- KPIs: Track average PR size, PR lifetime, and merges per developer per day.
- Reality Check: If your PRs live for days and contain thousands of lines, you are still doing feature-branch development.
Common Failure Mode
Teams adopt feature flags but still keep long-lived branches.
That is not trunk-based development.
The branch lifetime matters more than the branching strategy itself.
Final Thought
Trunk-based development feels uncomfortable at first because it goes against the natural desire to be “complete” and “polished” before sharing work. It requires you to prioritize the system’s flow over your individual comfort.
If you fix just one thing this month, make your pull requests radically smaller. Faster reviews, fewer bugs, and smoother delivery will follow. Everything else is just details.