So, I am not doing big development with hundreds / thousands engineers for quite some time. So I started to have sympathy to the other side of the story. The pr

So, I am not doing big development with hundreds / thousands engineers for quite some time. So I started to have sympathy to the other side of the story. The problem with feature branches, especially for frontend development, is that it is never just a "feature" (otherwise, you can gate it compile-time by just compiling out that feature module completely, or in nodejs terminology, treeshaking?). It is a combination of some new UIs, some updates to some interfaces, some new capabilities to a new middleware and some new APIs to call backend. And you don't want to gate these behind a feature flag. And merging these into main branch while make sure when multiple person working on a feature branch know what commits they did on feature branch is in main branch and why a merge from main branch would just absorb these commits are tiring. In these cases, trunk based development is really working for cases that not every developer is a git guru and can just navigate the merge back forth from main branch to feature branch and back. Yes, for these, subversion / perforce makes more sense, but everyone who is not git guru is still on git. That coupled with inefficiencies of your CI system only runs on main branch and needs manual adjustment to run on a feature branch every time, it is easier to do it on the trunk. Every problem is a tools problem, and people picks least resistance to make tools do what they want. There is no right or wrong, pick your poison wisely.