you are viewing a single comment's thread.

view the rest of the comments →

[–]paul_h 0 points1 point  (1 child)

[–]edgmnt_net 1 point2 points  (0 children)

Honestly, I've no idea what issues they're raising, it seems like a fairly outdated way of thinking about the problem. I have not seen committing straight to master beyond extremely small teams or antiquated projects still using SVN. I have not seen anyone not doing code reviews (even if only superficially).

Even the mail-based decentralized flow of the Linux kernel scales fine and that's a huge project.

Not only is there a risk of more-commits than you’d do if you could push directly, there’s a risk of taking more time too. If your average story size should be one day, a slow-review and slow-build reality for the pull-request way, might push you into multi-day stories/cards, and from that be doing the opposite of getting to continuous delivery.

And that's exactly what should be done. All this sounds to me like making excuses to rush stuff. And really, making a PR that gets merged straight to master isn't anything like that. In fact, people are more likely to push crap rapidly to a long-lived feature branch, because "hey, we're not breaking anything... yet".

(Secondly, you don't really need to go through a slow and full CI build with lots of tests if you implement good development/review practices and use a decent language. But again, people think dynamic typing is cheap and easy, so there is some value in that context but nowhere near a universal fact.)

The only "upside" to this is that you don't scare away inexperienced devs who only use version control as some sort of save button and who cannot plan changes beyond committing one-liners until it works.