[anchochilis]

This blog post reads like it's written by someone using Subversion back in 2015. Most of the justification for committing on mainline can be addressed by following other best practices:

1. Run the same suite tests additional quality checks (linters, etc) on PR branches that you run on mainline

2. Run branch CI against the merge commit for your PR branch (i.e. include your changes as well as latest mainline)

3. Avoid long-lived branches.

If you run into frequent merge conflicts and incompatible changes in an area of your codebase such that your team needs to integrate individual commits every half-hour instead of keeping 1-4 day feature branches around... That sounds like a code and/or organizational smell.

However!

> Using pull requests for code changes by your own team members is like having your family members go through an airport security checkpoint to enter your home. It’s a costly solution to a different problem.

I actually do like this analogy -- but it's not PRs that are the problem, it's mandatory reviews. And the cost/benefit of mandatory reviews varies widely depending on how senior the engineers on the team are, how much their work overlaps, and what their average tenure on the team is.