I tend to view it like this too. I'm in control of the new feature on my branch, it's my responsibility to rebase to avoid a nasty merge, I can then run automa

I tend to view it like this too. I'm in control of the new feature on my branch, it's my responsibility to rebase to avoid a nasty merge, I can then run automated tests and I can push my work at a point where I'm ready in a set of logical and atomic commits. I agree I think both have their pro's and con's. You can do trunk based development badly where your mainline is always broken, and you can do feature branching badly where you sit on a branch for months and then break the world when you merge. I have not seen a lot of success with pull requests. Usually people just seem to say LGTM, then the original developer merges. That could just be the company I keep. Either way, I don't see them as a significant benefit of feature branches. I'm not sure of the terminology as I've stepped away from development, but we used to work by the whole team working on a release branch, then merging to main at stable points. Maybe that gives the best of both worlds in terms of stable trunk and keeping continuous integration?