DevOps & CI/CD

Git Flow

Модель ветвления с долгоживущими ветками develop и release — и её главная альтернатива, trunk-based development.

Что такое Git Flow

Git Flow (gitflow) — модель ветвления в Git, описанная Винсентом Дриссеном в 2010 году. Она задаёт строгий набор веток и правил: какая от какой создаётся, куда вливается и когда удаляется.

Сам Git никаких моделей не навязывает — он даёт только ветки. Git Flow, GitHub Flow и trunk-based development отвечают на вопрос «как командой этими ветками пользоваться, чтобы не мешать друг другу».

Ветки Git Flow

Ветка	Живёт	Откуда	Куда вливается
`main` (`master`)	Вечно	—	Только релизы, каждый коммит помечен тегом
`develop`	Вечно	`main`	Основная ветка интеграции
`feature/*`	Дни-недели	`develop`	`develop`
`release/*`	Дни	`develop`	`main` и `develop`
`hotfix/*`	Часы	`main`	`main` и `develop`

main     ──●─────────────────●──────────●──   (v1.0, v1.1, v1.1.1)
            \               / \        /
release      \         ●───●   \      /       (стабилизация)
              \       /         \    /
develop  ──●───●─────●───────────●──●─────
            \ /       \             /
feature      ●         ●───────────●         (разработка)

Ключевая идея: main всегда содержит ровно то, что стоит в production; вся текущая работа идёт в develop; релиз стабилизируется в отдельной ветке, не блокируя разработку.

git switch -c feature/auth develop     # начать фичу
git switch develop && git merge --no-ff feature/auth

git switch -c release/1.2 develop      # начать релиз
git switch main && git merge --no-ff release/1.2
git tag -a v1.2 -m "release 1.2"
git switch develop && git merge --no-ff release/1.2   # не забыть вернуть фиксы

Что такое trunk-based development

Trunk-based development — противоположный подход: одна главная ветка (trunk, обычно main), в которую все вливаются напрямую или через короткоживущие ветки в пределах одного-двух дней. Никаких develop и release.

Как это работает без хаоса:

ветки живут часы, а не недели — конфликты не успевают вырасти;
каждый merge проходит CI: красная сборка не вливается;
незаконченная функциональность прячется за feature flag и уезжает в prod выключенной;
релиз — это тег на main или просто выкатка текущего main.

Именно эта модель делает возможным Continuous Deployment: деплоить несколько раз в день из develop с недельными релизными ветками невозможно.

Git Flow vs trunk-based

	Git Flow	Trunk-based
Долгоживущие ветки	`main`, `develop`, `release`	Только `main`
Время жизни ветки фичи	Недели	Часы, до 1–2 дней
Частота релизов	Раз в недели/месяц	Несколько раз в день
Конфликты слияния	Крупные и болезненные	Мелкие и частые
Незавершённый код	В ветке	В `main` за feature flag
Требования к тестам	Умеренные	Высокие, CI обязателен
Кому подходит	Версионируемые продукты, коробочный софт, несколько поддерживаемых версий	SaaS, веб-сервисы, одна версия в prod

Сегодня Git Flow принято считать избыточным для веб-разработки: автор модели сам добавил к оригинальной статье примечание, что для непрерывно поставляемых сервисов лучше подходят более простые схемы. Он остаётся оправданным там, где реально существуют несколько поддерживаемых версий продукта.

GitHub Flow — компромисс

Промежуточный вариант, самый распространённый на практике: одна ветка main + ветка на задачу + pull request с code review + автодеплой после слияния.

git switch -c fix/timeout main
git push -u origin fix/timeout
# → pull request → CI → review → merge → автодеплой

От trunk-based отличается обязательным PR как воротами, от Git Flow — отсутствием develop и release.

Что выбрать

Смотрите на частоту релизов. Выкатываете несколько раз в день — trunk-based или GitHub Flow. Выпускаете версии, которые поддерживаете параллельно (v2.3 у одних клиентов, v3.0 у других), — Git Flow оправдан. Промежуточный признак: если ветка фичи живёт дольше недели и её слияние вызывает страх — модель уже не работает.

Связанные термины

Git — ветки, merge и всё остальное
git rebase — чем причёсывают ветку перед слиянием
Команды Git — базовые операции
CI/CD — без него trunk-based невозможен
Code review — ворота перед merge
Стратегии деплоя — что происходит после слияния

Готовы запустить GPU-задачу?

Запустить GPU-сервер