DEV Community

Discussion on: The Case Against Pull Requests (And How to Fix Them)

Collapse
 
almostconverge profile image
Peter Ellis

This is what tools like Gerrit are for.

But the basic idea is that you don't actually push to master, you push to a review queue instead, where you can still amend your commit, and when it is finally approved, it is then merged with master.

And yes, this could easily mean that you've got merge conflicts again, so you're back to square one. Which is the Achilles heel of the whole idea, you now have to do the very thing you were supposed to avoid.

There is a difference though.

All this extra work is only needed when a commit fails the review. So if 99% of your commits pass review, all you're doing is pushing to one remote and pulling from another, which takes no extra effort in practice.

But if you're working with a "novice" team who are likely to fail reviews often, this workflow is a nightmare. And if you've only got two or three devs actively working on a codebase, it's probably an overkill.

So the important thing as always, is to think about what works for your specific circumstances, try your idea, then continuously evaluate and refine it.