> The industry solution to this problem is adding a merge service in the loop to protect your main branch from these harder-to-find conflicts.

Or maybe just:

1. Catch this during code review?

2. Run unit/integration/regression tests on PRs?

This just feels like another post from a vendor who wants to "sell you a DevOps" when proper culture and process is probably the better answer.

> 2. Run unit/integration/regression tests on PRs?

The blog walks through the situation where tests against a PR won't catch this.

It actually says that the test will catch it hours later and that the assertion will fail?

The contrived example would only ever happen if the developers in question didn't talk to each other. A lack of coordination is the real problem and cannot be solved by tooling. You can never tool your way out of a communication problem.

Everywhere I've ever worked has built and maintained their own solution for this. Seems a bit silly, like maintaining your own CMS or something.

Github's "require branch to be up to date" setting helps, but doesn't really scale beyond a few engineers in one repo. We tried this where I worked, but after ~6 people, rebasing feature branches got way too annoying.