Команда из 40 инженеров, несколько параллельных релизов и hotfix'ы в production. Выберите и обоснуйте стратегию ветвления (trunk-based development, GitFlow или их гибрид) для такой команды. Обсудите компромиссы, риски и критерии выбора — единственного правильного решения может не быть.?

Короткий ответ

Для 40 инженеров с несколькими параллельными релизами жизнеспособны и trunk-based с feature flags (минимизирует merge-боль, требует зрелой CI/CD), и схема с release-ветками на каждую поддерживаемую версию плюс строгий процесс cherry-pick hotfix'ов (даёт изоляцию релизов, но увеличивает нагрузку на слияние); выбор зависит от числа одновременно поддерживаемых в production версий.

Как это работает подробнее

trunk-based держит одну главную ветку, в которую непрерывно мержатся маленькие изменения, скрытые за feature flags; это требует сильного автоматического тестирования, так как main должен быть постоянно готов к релизу. Схема с release-ветками изолирует стабильность каждой версии, но требует явного переноса фиксов между ветками.

Пример кода

Пример конфигурацииКопировать

Вариант A (trunk-based + flags):
main ← короткие PR (≤2 дня) ← feature flag "new_pricing_v2" выключен в проде
hotfix: обычный PR в main + ускоренный деплой
Вариант B (release branches):
release/2.3 ← hotfix вносится сюда, затем cherry-pick в main и release/2.4
Риск: забыли cherry-pick в release/2.4 → регрессия вернётся в следующем релизе

Что использовать на практике

• Рекомендация. если поддерживается только последняя версия в production — trunk-based масштабируется лучше на 40 инженеров; если параллельно поддерживаются несколько версий у разных клиентов — release-ветки неизбежны, и важна автоматизация бэкпортов.
• Компромисс. trunk-based снижает merge-overhead, но перекладывает риск на дисциплину тестирования и управление feature flags (технический долг от забытых флагов); release-ветки дают предсказуемую изоляцию версий, но создают операционную нагрузку на синхронизацию фиксов. Критерий выбора — число одновременно поддерживаемых версий и зрелость автоматизированного тестирования.

Подводные камни

• Риск. внедрять trunk-based без зрелой культуры feature flags и быстрого CI — получают нестабильный main; выбирать классический GitFlow для команды с ежедневными релизами «по традиции», не оценивая, что модель создавалась для редких дискретных релизов.