git-flow против trunk-based

Зачем модель ветвления

Ветки в git дешёвые, но без договорённости команда быстро тонет в хаосе: какие ветки долгоживущие, куда вливать, как выпускать релиз. Модель ветвления — это и есть такая договорённость. Двух хватает, чтобы понять весь спектр: git-flow и trunk-based.

git-flow: много долгих веток

git-flow держит несколько постоянных веток:

• main — то, что в проде,
• develop — основная ветка разработки,
• feature/* — ветки под задачи, вливаются в develop,
• release/* — подготовка релиза,
• hotfix/* — срочные правки прямо в прод.

Фича делается в feature/, вливается в develop, потом из develop собирается release/, который после тестов уходит в main. Схема подробная и подходит, когда релизы редкие и версионируемые (десктопный софт, библиотеки с явными версиями).

Минус — тяжесть. Долгоживущие ветки расходятся, слияния болезненные, изменение долго едет от feature до прода. Для частых деплоев это медленно.

trunk-based: одна основная ветка

trunk-based переворачивает подход. Есть одна основная ветка (main, «trunk»), и все вливаются прямо в неё мелкими частыми коммитами. Ветки под задачи живут часы или день, не недели.

feature (живёт день) → merge в main → деплой

Ветки короткие, поэтому почти не расходятся и не дают merge hell. main всегда в рабочем состоянии, из него в любой момент можно выкатиться. Это модель команд с CI/CD и частыми деплоями.

А как же недоделанные фичи

Главный вопрос к trunk-based: если всё вливать в main быстро, как быть с фичей, которая ещё не готова? Ответ — feature-флаги. Код вливается в main, но спрятан за флагом и выключен:

if (featureEnabled("new-checkout")) {
    newCheckout();
} else {
    oldCheckout();
}

Фича едет в прод выключенной, её включают отдельно, когда готова. Без отдельной долгой ветки. Это позволяет вливать незаконченную работу, не ломая прод, и развязывает «выкатить код» и «включить функцию».

Что выбирать

• Редкие версионируемые релизы, нужны release/hotfix-ветки — git-flow.
• Частые деплои, CI/CD, командная скорость — trunk-based с feature-флагами.

Современный веб и SaaS тяготеют к trunk-based: он быстрее и меньше конфликтует. git-flow остаётся там, где релиз — это явная версия, которую готовят и выпускают.

Что важно запомнить

Модель ветвления — командная договорённость, как вести ветки и выпускать релизы. git-flow держит много долгих веток и подходит редким версионным релизам, но тяжёл и конфликтен.

trunk-based вливает мелкие частые изменения в одну ветку; ветки короткие, merge hell почти нет, main всегда готов к деплою. Недоделанное прячут за feature-флагами.

Частые деплои и CI/CD тяготеют к trunk-based, явные версии — к git-flow.

В связке с CI/CD: trunk-based и есть основа непрерывной доставки, где каждый коммит в main может уехать в прод.