Back when I started at my current job... 15 years ago... We had no central git server. No PR workflow. We just git pull-ed from each others machines. It worked better than you would expect.
We then went to using a central bare repo on a shared server, to hosted gitlab(? I think - it was Ruby and broke constantly) eventually landing on GitHub
This is classic git usage. A "pull request" was literally just asking someone to pull from your branch. GitHub co-opted the term for their own thing.
The thing that people really don't seem to get these days is how your master branch is a different branch from someone else's master branch. So pulling from one master to another was a normal thing. When you clone you get a copy of all the branches. You can commit to your master branch all you want, it's yours to use however you want to.
I've run into so many people that think "git pull" doesn't do anything unless you run "git fetch" first.
In my 10+ year career, I'm not sure I've ever run "git fetch" manually. I've never had a time where I wanted to fetch upstream changes, but not merge (or rebase) them into my branch.
Yeah, I don't remember having done that either. But I've often had changes where the merge failed because of un-checked-in changes, and then it was convenient to be able to run `git merge` after checking in the changes rather than `git pull` because it didn't need to talk to the remote.
We then went to using a central bare repo on a shared server, to hosted gitlab(? I think - it was Ruby and broke constantly) eventually landing on GitHub