Git flow, trunk-based, feature branches

Желательно~3 мин чтенияУровень: middle

Зачем это на собесе

Ждут сравнения стратегий и связи с частотой релизов и CI/CD.

Объяснение

Стратегия	Ветки	Когда
Git flow	`main`, `develop`, `feature/`, `release/`, `hotfix/*`	версионные релизы, мобильные приложения, редкие выкладки; тяжеловесна
GitHub flow	`main` + короткие feature-ветки + PR	непрерывная доставка веб-приложений
GitLab flow	`main` + окружения (`staging`, `production`) или релизные ветки	окружения и контролируемые релизы
Trunk-based	один `main` (trunk), очень короткие ветки (часы/1–2 дня) или прямые коммиты, feature flags	зрелый CI/CD, частые релизы, высокая автоматизация

Trunk-based development:

Небольшие частые интеграции в main (минимум раз в день).
Незавершённый код скрывается feature flags.
Обязательны быстрые автотесты, ревью небольших PR, защищённый main.
Релизы — по тегу/ветке релиза (release/1.4) от trunk.
Плюс: нет долгоживущих веток и «ада слияний»; минус: требует дисциплины и инфраструктуры.

Feature branches:

main:      A──B──────────────G──H
            \                /
feature/x:   C──D──E──F─────/       (PR → review → CI → squash/merge)

Соглашения по именованию: feature/ORD-123-order-filters, fix/…, hotfix/…, chore/…, release/x.y.

Защита main: обязательные ревью, зелёный CI, запрет force-push, линейная история, CODEOWNERS, подписанные коммиты (по необходимости).

Выбор зависит от: частоты релизов, размера команды, зрелости тестов и CI, необходимости поддерживать несколько версий (тогда release-ветки).

Git flow или trunk-based?

Git flow — для версионных релизов и редких выкладок; trunk-based — для частых релизов с сильным CI и feature flags.

Как выкатывать недоделанные фичи в trunk-based?

Скрывать за feature flag и включать после готовности.