While this article provides some valid and in-depth critic of the "PR workflow", I don't think a better alternative is suggested.

1. Some features do not make sense as smaller, daily commits. Doing so would probably require the developer to spend a lot of time putting in temporary "enable/disable" checks in place for half-baked functionality which could instead have been utilised towards actual feature.

2. PRs provide the flexibility for only a subset of team members (whoever suits best) being able to review a feature. With daily commits, everyone is forced to review or worst, halt, their work until the issues from a previous buggy merge are fixed. This is less than ideal for a large team where everyone is working on sufficiently different features such that they would need to spend considerable amount of time to understand the nuances/historical background on a different feature.

I just don't feel "everyone knows everything enough to review anything" is a practical assumption.

3. For cross-functional features in a micro-services architecture, it makes sense to have a standing PR that the other team can checkout to work against the new feature, while at the same time being able to checkout main branch if need be. Think of a frontend dev having to wait for someone to fix the backend main branch.

4. Especially for backend features where substantial database schema changes might be required, daily merge can be a nightmare for everyone in keeping their DB sane. PRs allow for multiple back-and-forth iterations to happen on DB schema before the final merge which is much more cleaner.

IMO, the positives behind PR far outweigh the negatives. A good practice of CR (?) - "continuous rebasing" can mitigate almost all major issues.