[gregmac]

I echo this. No pull requests is awful. The only time it's worked well for me is with 2 or 3 people sitting next to each other, with the same mindset and coding style.

Every other time I've seen or worked with teams doing it, their codrle is, well, bad. It "works" but it is full of stuff half-done, "we'll clean that up later" - except it's been there for 3 years. And I'm looking at it because I'vr narrowed down a production problem I was called in to debug, that turns out to be crappy error handling with terrible logging that mislead everyone on what was going on. A proper PR should have flagged that and asked for something slightly better than logging "something went wrong" in an try..catch statement that spans many hundreds of lines of code.

Small, focused PRs are good. Easy to review, code gets merged fast, conflicts are minimized. Massive PRs are bad, they are hard to review (problems get missed) and slow to get approved. If they get reverted because of a problem it's a mess to fix. PRs that do multiple separate things (fix two unrelated bugs, add a feature, and reformat spacing in 30 files) are impossible.

If PRs are small and focused, the duration of time the branch is open, number of commits and the actual branching model does not matter.

Long lived branches are a pain to the author (they're who has to merge Main and resolve conflicts), but that's their choice.