Какой Git-flow использовался на вашем предыдущем проекте?

На предыдущем проекте мы использовали классический Git-flow с двумя долгоживущими ветками — main (стабильный релиз) и develop (интеграция). Это был типовой веб-сервис на Java с релизным циклом раз в две недели.

Вот как это выглядело на практике:

• Feature-ветки создавались от develop. Название включало номер задачи из Jira: feature/API-123-fix-auth. После код-ревью и прохождения тестов вливали обратно в develop через merge, без squash — чтобы сохранить историю коммитов.
• Release-ветки (release/2.4.1) от develop за неделю до релиза. В них только багфиксы — никаких новых фич. После релиза вливали в main с тегом (v2.4.1) и обратно в develop, чтобы не расходились.
• Hotfix-ветки (hotfix/2.4.2-critical) от main для срочных правок в продакшене. После фикса — вливали и в main, и в develop.

Проблемы, с которыми сталкивались:

• Частые конфликты при мерже release обратно в develop, если кто-то забывал это сделать сразу. Решили автоматизацией — скрипт в CI создавал PR для обратного мержа.
• Разрастание develop при параллельной работе 5+ человек — приходилось делать ребазы перед мержем, чтобы история была линейной.

Из личного опыта: Git-flow оправдан для команд от 3 человек и регулярных релизов. Для соло-проектов или непрерывной поставки (как в мобильной разработке) он избыточен — там проще trunk-based с feature toggle.