You Might Be Better Off Without Pull Requests

hamvocke.com

12 points·aard··4 comments

In real (read enterprise) world you have things like SOC2 which mandates review by other people.

If you are 5 person startup, sure, commit straight to main.

Even in enterprise you should merge soon and live without long living feature branches but a PR where you run tests, static code analysis etc and get another eyes on is a good thing. With trunk based development the main goes straight to prod so you probably want to spin up the code for some testing anyway.

Wow, this is a very well-written article. I have experienced a lot of this in my own experience as a software developer.

This makes me wonder, the concept of pair programming has been around for a very long time. And yet, pull requests have grown in popularity while the use of pair programming remains pretty limited.

Does that mean that companies want to operate like a bunch of individuals instead of a team? Is independence valued more than speed & collaboration when it comes to software development teams?

Pairing doesn't replace code review because the reviewer needs to see the finished branch with fresh eyes, unbiased by discussion and false starts, to know whether it's safe and clearly explained in writing for every oncall in the future.

(I also need peace and quiet to think.)

A "trusted team" pushing unreviewed code to prod is breathtakingly reckless. I don't trust anyone to do that. Not even myself. Please review my code, because our customers matter and so does oncall's peace and quiet.

On svn we reviewed finished feature branches and merged them to the next release branch every few days, though svn routinely crapped itself on spurious conflicts like renames. Git just enables this reliably.

Reply on news.ycombinator.com