На заре своего становления как программиста я использовал trunk-based development (TBD). Если это подходит для Гугла, Нетфликса и Фейсбука, с их тысячами коммитов в день — подойдёт и для меня. Логично же. Там не тупые ребята сидят, между прочим. Я проработал так примерно полгода, пока на проект не пришли ещё два трейни. И этот ваш TBD оказался полной хренью. Ну неудобно же! Постоянно конфликты, постоянно что-то отваливается. Кто это вообще придумал? Мы тут с тремя коммитами справиться не можем, а они в своём Гугле тысячу в день льют... В общем, мы посовещались — и перешли на GitFlow. А всё почему? А всё потому, что мы неправильно понимали TBD. Оказалось, что это не ARAM (All Random All Master). Если ты пушишь в мастер по вечерам, а утром пуллишь обратно — это не TBD. Даже если ты пушишь с ребейзом, запустил тесты локально, делаешь merge request вместо прямого пуша в мастер — это все равно не trunk-based development... Сейчас trunk уже нельзя представить без Merge Queue / Train — чтобы никто не ломал master. - Без быстрого CI/CD — иначе ваши частые мержи будут висеть на длинных пайплайнах. (А если нет частых мержей, зачем вообще брали trunk?) - Без feature flags — иначе вы не сможете запушить незавершённые фичи или быстро отключить фичу в случае фейла. - Без короткоживущих, атомарных, итеративных веток — иначе получите большой дрейф и конфликты. Короткие MR — это основа trunk-ритма. - Без быстрых автотестов (unit + integration) на каждый мерж. - Без observability и алертов. (Формально это про CD Maturity, но я готов спорить до хрипоты, что это неотъемлемая часть любого флоу.) Вот и получается, что trunk — это не про одну ветку и не про “пушим в мастер”, а про зрелость команды и процессов, без которых всё превращается в ARAM и merge-hell. Если у тебя эталонный trunk — похвастайся, бахни 😇 (если только на словах — 👻) #GitFlowRelease