1. Feature branches that get merged into master via PR in GitHub
2. Sprint branch, bug fix branch, and master
3. Developers push directly to master (or if they really need a code review, push to a branch)
So far I prefer 3 the most, then 1, and I hope I never have to do 2 again. 3 is fastest, and we write a lot of Go so many of the comments I would have made on a Python PR for example aren't necessary.
PRs are a wonderful mechanism to provide smooth but gated access to the code for people outside the owning team who otherwise would not have it at all; but inside the team, I think: just because you can do it does not mean that you should.
Currently at work, my team currently pushes directly to master, or sometimes to a branch that is merged depending on the size of the work. Code is autodeployed to a staging environment, and then manually promoted to production a few times a week after smoke testing.
Commits to master don't get automatically deployed, and we deploy manually to staging then to production. I like the idea of automatically deploying to staging. It takes one more step out of the process.
When I worked at #2 there were 0 tests, which I believe is why management was often so afraid to deploy. Of course things are going to break if there are no tests. It took me a year to convince them to add unit tests, but we got there eventually.