Code Review approaches for Trunk-Based Development
When your team adopts Trunk-Based Development, one thing becomes immediately clear: traditional, heavy PR processes don’t fit. TBD thrives on small, frequent, and safe commits to a shared mainline.
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!5t
Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!
As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇
Now, let's dive into today's micro-topic!
In short
👯 Collaborative programming like Pair and Mob Programming offers immediate code review and strong knowledge sharing. Ideal for onboarding or working on critical paths, they promote continuous learning but require real-time availability and focus from all participants.
🌿 Short-lived Pull Requests still have a place in Trunk-Based Development—if used with discipline. PRs must act as alignment tools, not bureaucratic gates that slow development flow.
⚙️ Patch review systems, like those used at Google, provide a structured and scalable alternative. Reviews occur before commits hit the trunk and involve patch sets separate from the VCS.
🔄 Post-commit review flips the model by letting developers push first and review later. It demands high confidence, great test coverage, and mature CI pipelines to catch issues quickly.
🚢👀❓ Ship Show Ask introduces a flexible mindset for deciding when and how to seek feedback.
Small, frequent, and safe commits
When your team adopts Trunk-Based Development (TBD), one thing becomes immediately clear: traditional, heavy Pull Request processes don’t fit. TBD thrives on small, frequent, and safe commits to a shared mainline. That changes how you approach code reviews. You can’t afford long-lived branches or delayed approvals—every minute counts.
Let’s explore the main review patterns used by high-performing TBD teams, what they enable, and where they shine.
1. Social Programming (Pair or Mob) 👯
The most immediate and collaborative review method is having someone with you as you code. In Pair Programming, two developers work side-by-side (or virtually), constantly reviewing each other’s work. Mob Programming extends this to the whole team.
🔁 Review happens in real-time
🧠 Enhances knowledge sharing
🎓 Builds team skills and cohesion
⚡ Ideal for critical code paths or when onboarding
This method is review by design, not as a separate step. It eliminates bottlenecks and makes high-quality commits the default. The cost? It requires presence and planning—everyone must be available and focused.
2. Pull Requests (PRs) with Short-Lived Feature Branches 🌿
Still widely used—even by teams doing TBD—short-lived PRs can work well if you respect the small batch size rule. The danger is using PRs as mini-projects instead of micro-changes.
The goal here is to keep the feedback loop fast:
⏱️ Branches last less than a day
🔍 PRs focus on a single change or small enhancement
💬 Reviews are timely (ideally within hours)
🧪 Automated checks run before and after merging
The success of PRs in TBD comes down to discipline. Use them as checkpoints for alignment—not approval gates that delay flow.
3. Patch Review Systems (Google-Style) ⚙️
Inside Google, since the early 2000s, code review evolved around patch sets outside the version control system (Perforce). The review is coupled to single commits, not entire branches. This is not your typical GitHub PR workflow.
📦 Changes are submitted to a separate database as patch sets
🔍 Reviews happen before the code reaches trunk
🔐 A gatekeeper ensures quality and standards
🔁 Fast, continuous feedback and approvals
This model works well in large-scale environments with strong tooling. It promotes commit hygiene, rapid integration, and removes branch management overhead. It’s the model that inspired tools like Gerrit.
4. Post-Commit Reviews 🔄
Commit first, review later. In Post-Commit Review, developers push directly to the trunk, and peers review the changes after the fact.
⚠️ Requires confidence and test coverage
🧪 Automated pipelines must catch regressions
🔄 Feedback is logged and discussed after the merge
🔧 Rollback or follow-up fixes are used if needed
This method isn’t for beginners. But in high-trust, high-skill teams, it’s a game-changer. It minimize bottlenecks and reinforces responsibility. To work, it requires you have a solid CI and a team culture that supports rapid learning and recovery.
5. Ship Show Ask 🚢👀❓
Emerged from an article from Martin Fowler, Ship Show Ask is a hybrid mindset. Traditional workflows often force us to choose between autonomy and oversight. But what if we could rethink that? That’s where the Ship / Show / Ask model comes in—a lightweight framework that empowers teams to work quickly while still encouraging collaboration, learning, and safety. Every time you make a change, you make a decision: Should I Ship it? Should I Show it? Or should I Ask for feedback before it goes live?
Ship: Just Go For It → In its purest form, this is Continuous Integration: you write a change, you’re confident in it, and you commit directly to
main. No code review required, no pull request, no waiting. You trust your tests, you trust the team, and you trust yourself.Perfect for: Minor changes, major changes implemented in a known pattern, low-risk changes in general, or applying feedback from a previous review.
Show: Merge Now, Talk Soon → You open a pull request, wait for your automated checks to pass, and then merge it yourself. The PR stays open (or gets auto-merged), creating a space for async feedback—after the fact.
Perfect for: Sharing a new approach or pattern, refactoring something and wanting opinions, fixing a tricky bug and showcasing how, inviting feedback with a not blocking progress.
Ask: Wait and Collaborate → You’ve made a change, but you want input before it goes live. Maybe you’re experimenting. Maybe you’re unsure. Maybe you just want a sanity check before pushing the button. This is where deep conversations can happen.
Perfect for: Exploring a new pattern or architecture, needing help refactoring or naming things, trying something that affects a broad surface area, working on something sensitive, ending the day and wanting a second pair of eyes before merging tomorrow.
🚦 Choosing What Fits
No single code review style is necessarily the "best" in every context and situation. The right approach depends on your:
📏 Batch size (how big are your changes?)
⏱️ Review latency (how quickly do you need feedback?)
👥 Team trust and skill level
🛠️ Tooling and CI reliability
In general, you should strive for the smallest batch sizes possible, and for the “more CI” approaches possible. But one rule holds: in TBD, code review must support flow, not block it, and the goal is always the same: deliver working software frequently, safely, and with shared understanding.
Until next time—happy coding! 🤓👩💻👨💻