An organization might identify that merging large features into trunk has destabilized the product and conclude, “We need tighter controls on when things merge. We should merge less frequently.” This leads quickly to every team or every feature having separate dev branches. Whenever any branch is decided to be “complete,” it is tested and merged into trunk, triggering some potentially expensive work for other engineers still working on their dev branch, in the form of resyncing and testing.
In decentralized cases, this often ends up as a persistent fork.
An example I know about: A "branch" was created for the TV version of an app, and at some point the task of merging back with the phone app was abandoned due to the cost of doing so. So, the TV and phone apps just stayed different fragmented apps — in features and user experience as well as code — and any effort to consolidate always ended up at the same conclusion: it's too much work.
