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/

Pt. 1 https://codecraftdiary.com/2026/04/04/trunk-based-development-why-most-teams-think-they-use-it-but-dont/

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.

The post Trunk-Based Development: From Chaos to Flow appeared first on CodeCraft Diary.