I think a big chunk of "why is the kernel's git workflow the way it is" is just "it's a formalized and tooled-up equivalent of the preexisting organizational st

I think a big chunk of "why is the kernel's git workflow the way it is" is just "it's a formalized and tooled-up equivalent of the preexisting organizational structure where everybody was emailing patches, submaintainers had kernel source trees on their local machines that they were in charge of, etc". That said, one area I suspect the 'branches in a common repo' model will have trouble is access control. With the kernel's approach I can set up a tree for the Foo subsystem without needing to have any kind of privileged access to the 'official' kernel tree: whoever I send Foo pull requests to chooses to accept them, or not, case by case. I don't get to make unreviewed changes to other bits of code. (Disclaimer: I haven't looked at github's access control model, maybe it lets you lock down master?) You can do kernel development with a "we give commit access out fairly freely" model, of course (I think some of the BSDs are like that, again as historical accident of the cvs style tooling they used to use); but Linux hasn't historically been socially organised that way, and changing tools is easier than changing organisational structure.