More or less. I'm inclined to agree. More than once, I've been burned when merging a long-lived feature branch, because it turns out that, during development, t

More or less. I'm inclined to agree. More than once, I've been burned when merging a long-lived feature branch, because it turns out that, during development, the behavior of some other portion of the system changed in a way that broke the behavior of what I was working on, without actually causing any compile-time or run-time errors. You can theoretically guard against that with more and more automated testing, but that's putting a lot of weight on a thing that's almost always full of things you forgot to test, or didn't think you needed to test. I've had better luck with feature flags. They don't take anything away from automated tests or static analysis. They potentially add a little bit more hassle in the form of maintaining the flags. (Not nearly as much hassle as sorting out a merge conflict, though.) The other, quite compelling, thing they add is a much wider expanse of time during which you can notice, "Huh, that's funny," when you're doing your mid-development ad-hoc testing. You can, of course, get a similar benefit by making a daily practice of rebasing your feature branch onto the latest version of the main branch. But my experience has been that doing that is annoying, and the thing about annoying things that you have to actively remember to do is that it's surprisingly easy to just not remember to do them.