Ésszel kell csinálni mindent. Illetve a legnagyobb hibák közé tartozik a verziókezelést a szoftver architektúrától függetlenül kezelni. Láttam már sok millió EUR-os fejlesztést bedőlni emiatt (is).
Az egy valós veszély, amit írsz, hogy szemetes lesz a trunk based dev miatt a kód, viszont pont a trunk based dev miatt ki is lehet dobálni a már nem használt kódot gyorsan.
Ha külön branchon nagyon elágaznak a fejlesztések, esetleg jó kis szaftos refaktorálások történnek egymástól függetlenül különböző branchokon, veszélyességi pótlékot kell fizetni annak, aki majd összemergeli a kettőt. Ezt a divergenciát próbálja megakadályozni a trunk based development. Nem véletlen, hogy a Facebook és a Google is ezt nyomja, mert az ő méretükben egyszerűen nem megy másképp. A trükk, amit alább már írtam, hogy nagyon megnehezítik a commitok bejutását a fába. Ahhoz, hogy valami bejusson, code-review-knak, teszteknek mind le kell futniuk hibátlanul.
És itt kapcsolódik hozzá a szoftver architektúra: a (runtime) feature flagek azért is jók, mert pl. tudsz rolling release-t csinálni és ami még fontosabb, ha gáz van, mindenhol kikapcsolni anélkül, hogy a legtöbb user egyáltalán észrevenne egy akármilyen súlyos hibát, ami a leggondosabb tesztelés mellett is előfordulhat. Ezek mellett nyilván szükség van compile time feature flagekre is, hogy feleslegesen ne menjen ki olyan, ami még messze nincs kész, vagy egy adott régióban, ahova a build kerül, nem is tervezik bekapcsolni.
Ui: nyilván nem atomerőmű- vagy repülővezérlés esetleg autó ECU firmware fejlesztésre gondoltam elsősorban a fentieknél.