Wow, this is a really extensive answer, thank you. I really like the pull request model encouraged (enabled?) by GitHub -- it codifies the code review process, which is handy, especially when automated testing isn't up to par yet. That said, for dev teams, I'm not totally sold on the process.

>Some not so git/github saavy organizations work out of a shared repo for reasons that aren't very clear to me.

I've used the private GitHub services (private repos and Enterprise) with different companies for different projects, and the whole GH workflow seems to encourage something pretty clearly outside the realm of continuous integration. While the people I've worked with/for have almost always said we were working on building out the "CI/CD pipeline," the pull request workflow always ended up as a blocking function stuffed inside what would otherwise be called continuous integration. It's not continuous at all -- it places the onus of "merges" on people looking at stuff instead of trusting the tests, which means tests never get written and PRs are humongous.

Anyway, my point is that I like working out of shared repos because it makes it easier to just totally bypass the pull request workflow, though you're right, it can present the opportunity for rebase nightmare destruction derbies. For open source projects and big distributed things, pull requests are invaluable. But it seems kind of counterproductive in most of the scenarios in which I've seen it.