It is certainly possible to avoid feature branches with multiple contributors working on the same areas. We've even been pretty successful performing major refa

It is certainly possible to avoid feature branches with multiple contributors working on the same areas. We've even been pretty successful performing major refactorings to substantial codebases in this way. The key is to do continuous integration properly - i.e. actually integrate your changes with the rest of the team several times a day. We actually deploy to production several times of day. This requires you to break down changes into very small steps that can be completed, tested, and deployed in an hour or so. Each small change is far less likely to break something, or cause performance degradation. If it does, then you know exactly what caused it without painful debugging. Each small change is unlikely to cause significant merge pain for the rest of the team. This requires you to have excellent automated testing and rapid <5min deploys. There are also tools like branch by abstraction and feature toggles which can help but are only tools. The key is how you work as a team. Feature branches are another way of working. They may be the only way of working in many cases (e.g. distributed team of sporadic contributors). Feature branches are almost the opposite of continuous integration. By definition changes on the branch are not integrated.