You know the feeling. A pull request lands in your inbox. It’s 2,000 lines across 14 files. You skim the first few changes, see the pattern, hit approve, and move on. Three weeks later, a bug that should have been caught in review slips into production. Sound familiar?
We’ve all been there. Modern code review tools made collaboration effortless — and in doing so, they made review itself optional. The diff is so large that no human can meaningfully process it, so we don’t. We rubber-stamp. We trust. And then we pay.
That’s the silent failure mode of pull-request culture. And it’s exactly why Maiao — a tool that brings Gerrit-style per-commit review to GitHub, GitLab, and Gitea — deserves your attention. Not because it’s nostalgic. Because it’s honest.
“Large PRs are not reviewed. They’re rubber-stamped. If your review takes five minutes, it wasn’t a review.”
Gerrit fans remember a different world. Each commit gets its own review, its own discussion, its own approval. You can’t hide a sloppy intermediate commit behind a tidy squash-merge summary. You’re forced to think about how the code got there, not just that it got there.
One commenter on the Maiao announcement summed up the sentiment perfectly: “Gerrit. Now that’s a name I’ve not heard in a long time. A long time.” Another lamented that the tool doesn’t replicate Gerrit’s UI — “a wish someone would create such a thing for those of us forced to work on GitHub.”
But here’s the twist: Maiao isn’t about reliving the past. It’s about fixing a present that’s quietly broken. The default workflow for most teams is: branch off, make a bunch of commits, squash-merge into main, move on. The squashed history is a lie — it pretends the code emerged fully formed, when really it was a messy, iterative process. And that lie hides the very moments where review should have caught something.
When you review per-commit, you slow down. You see the author’s thinking. You notice the commit that introduces a bug and the next one that fixes it. You ask questions about why that decision was made at that point. It’s more work — but it’s the work you signed up for when you became an engineer.
The skeptics are loud. “Who is creating a separate PR for each commit on their feature branch?” one commenter asks. “Sounds like crazy town.” I get it. It sounds like overhead. But the overhead isn’t in the review — it’s in the thinking that’s missing today. Maiao makes the process manageable by automating the PR-per-commit dance, letting you stay on your local branch while each commit becomes its own reviewable unit.
“We didn’t need a new workflow. We needed the old one back.”
I’m not saying every project needs per-commit review. For tiny teams or trivial changes, it’s overkill. But if you’re managing large feature branches, if you’ve ever approved a 1,000-line PR without reading half of it, if you’ve ever felt that sinking feeling when a bug traces back to a commit you “reviewed” — then you owe it to yourself to try something different.
Maiao isn’t a silver bullet. It’s a mirror. It forces you to confront the question: Do you actually care about review quality, or are you just going through the motions?
The Gerrit generation knew the answer. It’s time to reclaim it.
FAQ
Q: Isn't per-commit review just extra overhead?
A: Yes, but it's the overhead that catches bugs. A 2,000-line PR is effectively unreviewable — your brain can't process it. Per-commit review breaks the problem into digestible chunks, forcing you to actually understand the code. That's not overhead; that's the job.
Q: What's the practical implication of using Maiao?
A: You stop hiding behind squash merges. Each commit gets its own review, so you can't bury a hack in a giant diff. It's a tool that enforces a discipline many teams claim they have but don't. If you care about review quality, it's a direct upgrade.
Q: Contrarian take: Is per-commit review actually worse for collaboration?
A: Some argue it creates too many small discussions and interrupts flow. But that's only true if you treat each commit as a standalone unit. In practice, Maiao lets you review a chain of commits in context — like reading a chapter, not a single page. The real contrarian take is that our current PR workflow is the one that's broken.