Когда команда больше одного человека, рано или поздно встаёт вопрос: как организовать работу с ветками в Git? Хаотичное ветвление — это мерж-конфликты раз в неделю, сломанный main и «кто запушил вот это в прод». Две самые популярные альтернативы хаосу — Gitflow и trunk-based development. Они кардинально разные по духу, и выбор между ними влияет на всё: как часто вы деплоите, насколько страшно делать релиз, насколько сложно ревью.

Что такое Gitflow и как он работает

Gitflow — это модель, которую Винсент Дриссен описал ещё в 2010 году. С тех пор она обросла инструментами, плагинами и целыми религиозными войнами в комментариях. Суть такая:

Есть две вечные ветки — main (или master) и develop. В main всегда стабильный код, который уже в проде или готов туда попасть. В develop — текущая разработка.

От develop отпочковываются feature-ветки под каждую задачу. Когда фича готова, она мержится обратно в develop. Когда набирается достаточно фич для релиза, создаётся release-ветка: там фиксят баги, обновляют версию, пишут changelog. Потом release мержится и в main, и в develop. Если в проде вдруг что-то сломалось — режется hotfix прямо от main, чинится, и снова мержится в обе ветки.

На бумаге — стройно. На практике — давайте посмотрим, где начинаются проблемы.

Плюсы Gitflow

Чёткое разделение стабильного и нестабильного кода. Main всегда в форме. Это важно, если у вас есть внешние зависимости от конкретного тега или если релизы согласуются с бизнесом.

Удобно при редких релизах. Если вы деплоите раз в две недели или раз в месяц — Gitflow под это заточен. Команда собирает фичи в develop, потом делает release-ветку, тестирует, выпускает.

Параллельная работа над несколькими версиями. Можно одновременно поддерживать v1.x в проде и разрабатывать v2.x в develop. Hotfix на старую версию — отдельная ветка от нужного тега.

Минусы Gitflow

Долгоживущие ветки — источник боли. Фича разрабатывается неделю-две, за это время develop уходит вперёд. Мерж превращается в детектив: что поменялось, откуда конфликты, всё ли работает вместе. Чем дольше живёт ветка, тем страшнее её мержить.

Overhead на поддержку самой модели. Все эти мержи туда-обратно между main и develop — лишние движения. Забыл смержить hotfix в develop — готовься к сюрпризу через месяц.

Сложно автоматизировать CI/CD. На каком этапе запускать тесты? На feature? На develop? На release? Всё это надо настраивать, и пайплайн становится запутанным.

Психологический барьер перед релизом. Когда релиз — это событие со своей веткой, согласованиями и ритуалами, команда начинает их бояться. Баг-фикс, который можно было выкатить за час, ждёт «следующего релизного окна».

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

Trunk-based development (TBD) — полная противоположность по духу. Здесь всё крутится вокруг одной ветки: main (или trunk). Разработчики либо коммитят прямо в неё, либо делают короткоживущие ветки (feature branches) на 1-3 дня максимум. Потом мержат в main. Деплой происходит из main — часто, иногда несколько раз в день.

Чтобы недоделанные фичи не ломали прод, используют feature flags (флаги фич): код уже в main, но скрыт за переключателем. Когда фича готова — включаете флаг.

Плюсы trunk-based development

Мерж-конфликты почти исчезают. Когда ветки живут день-два, разрыв с main минимальный. Конфликты — редкость, а не еженедельный ритуал.

Быстрый фидбэк. Код попадает в main быстро — значит, CI-тесты прогоняются на актуальном срезе. Если что-то сломалось, вы узнаёте сразу, а не когда мержите недельную ветку.

Простой CI/CD. Один пайплайн на один main. Понятно, где запускать тесты, откуда деплоить, как устроен артефакт.

Непрерывная интеграция — настоящая, а не номинальная. Martin Fowler называет это ключевым признаком зрелой команды: все разработчики интегрируют свой код в общую ветку минимум раз в день. При Gitflow это физически сложно — при TBD это норма.

Минусы trunk-based development

Требует дисциплины и культуры. Коммитить в main каждый день — это значит, что ваш код должен быть готов к этому. Тесты должны быть. Ревью должно быть быстрым. Если этого нет — TBD превращается в хаос.

Feature flags добавляют сложности. Управление флагами — это отдельная инфраструктура. Забытые флаги накапливаются как технический долг. Нужна система их ведения и регулярная уборка.

Сложнее при редких релизах. Если у вас SaaS и деплой раз в месяц по расписанию — TBD не очень вписывается в этот ритм.

Выше требования к тест-покрытию. Без хорошего набора тестов работа в main — это хождение по минному полю. Каждый коммит потенциально идёт в прод.

Какая стратегия подходит вашей команде

Нет универсального ответа. Есть факторы, которые помогают определиться.

Размер команды

Команда из 2-3 человек вполне живёт с упрощённым Gitflow или даже без него — просто feature-ветки и main. Классический Gitflow с release-ветками здесь избыточен.

Команда из 10+ человек при Gitflow начинает страдать: слишком много параллельных веток, сложная история, сложные мержи. TBD с feature flags здесь работает лучше, но требует договорённостей и инфраструктуры.

Частота релизов

Деплоите раз в месяц по расписанию, согласуете с клиентами или регулятором — Gitflow с его release-ветками создан для вас. Вы можете собрать релиз, протестировать его, прогнать приёмку, и только потом выпустить.

Деплоите непрерывно или хотите к этому прийти — TBD ваш путь. Именно он лежит в основе большинства команд, которые деплоят несколько раз в день.

Наличие CI/CD

Если у вас нет нормального CI/CD — с TBD будет больно. Без автоматических тестов и быстрого деплоя частые коммиты в main — это просто риск без пользы.

Гитфлоу более толерантен к ручным процессам. Выпускать релизы раз в две недели вручную — неприятно, но реально.

Тип продукта

Мобильное приложение, которое проходит модерацию в App Store: релизы редкие, версии поддерживаются параллельно, hotfix-ы нужны — Gitflow разумен.

Web-сервис, SaaS, API, где нет понятия «версия у пользователя»: TBD работает отлично, вы контролируете, что именно видит пользователь через feature flags.

Зрелость команды

Если команда только формируется, договорённостей мало, тестов почти нет — начните с Gitflow. Он явный, структурированный, предсказуемый. Каждый знает, в какую ветку что идёт.

Если команда опытная, есть культура ревью, тесты покрывают основной функционал, и вы хотите ускориться — переходите к TBD постепенно.

Гибридный подход: берём лучшее

Многие команды приходят к чему-то среднему. Вот практичный вариант:

  • Одна долгоживущая ветка — main.
  • Feature-ветки живут не больше 2-3 дней. Если фича большая — делится на части, каждая часть за флагом.
  • Релиз — это тег на main, а не отдельная ветка.
  • Hotfix — коммит прямо в main с тегом.

По сути — это TBD с некоторыми элементами структуры. GitHub Flow, который GitHub описал в 2011 году, работает именно так. Просто и эффективно для большинства веб-проектов.

Как перейти с Gitflow на TBD

Резкий переход — плохая идея. Лучше делать постепенно:

  1. Сократите время жизни feature-веток. Поставьте правило: ветка живёт максимум 3 дня. Если фича не влезает — делите задачу.

  2. Введите feature flags для крупных фич. Выберите инструмент: LaunchDarkly, Unleash, или просто конфиг в базе. Начните использовать его для новых больших задач.

  3. Автоматизируйте тесты. Без этого дальше двигаться рискованно. Хотя бы smoke-тесты и тесты критических путей.

  4. Упростите пайплайн. Уберите ветку develop. Один пайплайн — один main.

  5. Отмечайте релизы тегами, а не ветками. Тег — это неизменяемая метка на конкретный коммит. Hotfix — это новый коммит с новым тегом, не ветка от старого тега.

Что в итоге

Gitflow — не устаревший, не плохой. Он хорошо работает там, где его придумали: редкие релизы, параллельные версии, формальные процессы согласования. Это не значит, что его надо использовать везде по умолчанию.

Trunk-based development требует вложений — в тесты, в культуру, в инфраструктуру. Но отдача прямая: меньше мерж-конфликтов, быстрее деплой, проще пайплайн.

Когда в REEXY помогаем клиентам выстраивать процессы разработки вместе с созданием сайта или сервиса — почти всегда рекомендуем начать с простого GitHub Flow, и переходить к полноценному TBD по мере роста команды и зрелости процессов. Не потому что это модно, а потому что это работает на практике для большинства веб-проектов.

Главный вопрос при выборе не «что правильнее», а «что подходит нашей команде прямо сейчас». Стратегия ветвления должна снижать трение, а не создавать его. Если ваш Gitflow работает и команда довольна — не трогайте. Если мержи превратились в боль, а релизы — в стресс — пора что-то менять.