Ветвление удобно, если вы ожидаете, что работа НЕ будет выполнена вовремя, и у вас нет достаточного количества тестов для непрерывной интеграции. Я склонен видеть сумасшедшие разработки в магазинах, где задачи программирования слишком велики, чтобы их можно было предсказуемо выполнить, и поэтому руководство хочет дождаться выпуска, чтобы определить, какие функции должны поставляться. Если вы выполняете такую работу, то вы можете рассмотреть возможность использования распределенного управления версиями, где КАЖДЫЙ рабочий каталог является ветвью естественным образом, и вы получаете всю локальную регистрацию и локальную историю, которую вы можете съесть, не причинив никому вреда. Вы можете даже объединиться с другими разработчиками вне ствола.
Я предпочитаю, когда мы работаем в нестабильной магистрали с ветвями для кандидатов на освобождение, которые затем помечаются для выпуска и которые затем становятся потоком для аварийных исправлений. В такой системе у вас очень редко бывает больше трех ветвей (последний выпуск, кандидат на текущий выпуск, нестабильная магистраль). Это работает, если вы делаете TDD и имеете CI на нестабильной магистрали. И если вам требуется разбить все задачи, чтобы вы могли доставлять код так часто, как вам хочется (обычно задача должна занимать всего один-два дня и выполнимо без всех других задач, составляющих ее функцию). Таким образом, программисты берут работу, проверяют транк, выполняют работу, синхронизируют и проверяют в любое время все тесты. Нестабильная магистраль всегда доступна для ветвления в качестве кандидата на выпуск (если все тесты пройдены), и поэтому выпуск становится нештатным.
В целом, лучше означает: меньше веток, более короткие задачи, более короткое время выпуска, больше тестов.