I prefer to create linear git history, which can be fast-forward merged. This was a technical requirement at my previous job, which used BitBucket and required all PRs to be fast-forward-able. We had to always manually rebase onto latest master. A new company I recently joined, using AzureDevOps, likes to have small PRs all targeting master/main (AzureDevOps has nicer merge options like "Semi-linear Merge" (Rebase+Fast-Forward+Empty Merge commit) and "Rebase+Fast-forward".
However, some changes will build on top of others. So sometimes I need to create stacked PRs.
Git/PR branching strategy aside...
I have 9 outstanding PRs. They are mostly very tiny. Regardless, I have a lot of code that is not merged to master/main. Now I'm being strongly encouraged to work on some new feature, but my manager wants me to branch off of master/main, instead of using the latest infrastructure upgrades I've completed. I'd rather not build on top of old infrastructure because my PRs haven't been approved over the holidays.
The more general question here, is:
If you are on a "team" of 1, sometimes 2, developers, and your PRs are not getting reviewed at all, should you be branching off of master/main?
There are other developers not working in the codebase that often help with code review (I find this very odd). I am a front-end dev working in our front-end repo, but there are some (very smart) backend devs that have helped with code review for front-end. They don't necessarily have any mechanism where they prioritize code review for the front-end. Our backend devs have extremely high standards, and have consequently (somewhat) been throwing their hands up because PRs created by very-junior "overseas" developers are extremely large and not easy to review.
Long term I don't intend to stay on a team of 1, where we insist on code review.. but there are no developers that are impacted by code not being merged to master/main.
My original google search: software engineering stackexchange if PRs aren't being reviewed should you keep branching off of master/main
Related: Dealing with a large pull request