"The Pull Request workflow is so dominant now that it’s considered the default path for code to permanently enter into a repository."
Arguably this model has less to do with GitHub becoming dominant but with the fact that all of the large BigCorp/FAANG type companies now use a strict code review policy, and this has spread downwards (along with a bunch of other cargo cult-ed practices) into much smaller organizations.
The first 10-15 years of my career I never encountered a code review tool once, and it was just commit privileges granted or not granted and judicious use of branching and tagging. Then everybody seemingly started to switch from "I'll just go off and do my work on a branch and then we'll integrate" to "I don't trust anything anybody else has written and we'll review every single line".
I worked at Google for 10 years and when I emerged from there everyone had switched to code review, even small startups.
FWIW I see advantages and disadvantages to both approaches. But I don't think GitHub is to blame? Google clearly has an intrinsic interest in making sure things don't blow up $$ production, and are willing to sacrifice velocity all over the place to make sure of that. Same with projects like the Linux kernel, or GCC or LLVM or whatever. But...
(If anything, Git makes working on longer running feature branches a lot easier, and the whole code/pull review process made more sense with centralized systems like Perforce, etc. or systems like CVS or SVN that had terrible merge-on-merge support)
Based on my own experience I am quite sure that code review doesn't sacrifice velocity, it enables it. Unreviewed development has no way to ensure everyone is pulling in the same direction.
Totally agree! Code reviews are not only for 'making sure things don't blow up $$ in production.' If your team doesn't use pair programming, code reviews are the best opportunity to share knowledge and align vision and values across the team.
If you feel like code review conversations are taking too long and affecting your cycle time, then you can use the tool I created: https://pullpo.io to have these conversations on ephemeral bidirectional GitHub-Slack channels.
Arguably this model has less to do with GitHub becoming dominant but with the fact that all of the large BigCorp/FAANG type companies now use a strict code review policy, and this has spread downwards (along with a bunch of other cargo cult-ed practices) into much smaller organizations.
The first 10-15 years of my career I never encountered a code review tool once, and it was just commit privileges granted or not granted and judicious use of branching and tagging. Then everybody seemingly started to switch from "I'll just go off and do my work on a branch and then we'll integrate" to "I don't trust anything anybody else has written and we'll review every single line".
I worked at Google for 10 years and when I emerged from there everyone had switched to code review, even small startups.
FWIW I see advantages and disadvantages to both approaches. But I don't think GitHub is to blame? Google clearly has an intrinsic interest in making sure things don't blow up $$ production, and are willing to sacrifice velocity all over the place to make sure of that. Same with projects like the Linux kernel, or GCC or LLVM or whatever. But...
(If anything, Git makes working on longer running feature branches a lot easier, and the whole code/pull review process made more sense with centralized systems like Perforce, etc. or systems like CVS or SVN that had terrible merge-on-merge support)