Trunk-based development

Стратегия ветвления, при которой все разработчики интегрируют изменения в одну главную ветку (trunk/main) как можно чаще — несколько раз в день.

Зачем нужно

Долгоживущие feature-ветки накапливают конфликты и откладывают интеграцию. Trunk-based development (TBD) решает это радикально: ветки живут не более 1-2 дней, интеграция в main происходит постоянно. Это основа Continuous Integration: CI-пайплайн всегда смотрит на trunk и быстро сигнализирует о проблемах. Крупные компании (Google, Facebook, Netflix) используют именно этот подход.

Где используется

  • Команды с высокой частотой деплоя (несколько раз в день)
  • CI/CD-пайплайны, где каждый коммит в main запускает деплой
  • Как альтернатива Gitflow для продуктов без строгих релизных окон
  • Совместно с Feature Flags для сокрытия незаконченных фич в production

Основной контент

Основные принципы TBD

  1. Один trunk (main/master) — единственная долгоживущая ветка
  2. Короткие ветки — feature-ветки живут 1-2 дня максимум
  3. Частые коммиты — интеграция в main несколько раз в день
  4. Feature Flags — незаконченная фича скрыта флагом, а не веткой
  5. Стабильный trunk — main всегда в деплоибельном состоянии

Базовый workflow

# Утром: синхронизироваться
git switch main
git pull --rebase origin main

# Создать короткую ветку для небольшой задачи
git switch -c feat/add-search-field

# Быстро реализовать, покрыть тестами
# ... работа ...
git commit -m "feat: добавить поле поиска в хедер"

# Актуализировать ветку и отправить
git rebase origin/main
git push -u origin feat/add-search-field

# Создать PR → быстрое ревью (< 4 часов) → merge в main
# Удалить ветку
git switch main
git pull
git branch -d feat/add-search-field

Feature Flags вместо долгих веток

// Вместо ветки живущей месяц — флаг
if (featureFlags.isEnabled('new-checkout-flow')) {
  return <NewCheckout />;
}
return <OldCheckout />;

# Код фичи живёт в main, но скрыт флагом
git commit -m "feat: добавить новый checkout (за флагом)"

# Когда фича готова — включить флаг через конфиг
# Когда фича стабильна — удалить флаг и старый код

Release branches (при необходимости)

# Если нужны стабильные релизные ветки
git switch main
git checkout -b release/2.1.0

# Только cherry-pick критичных фиксов в release
git cherry-pick abc1234

# Тегировать релиз
git tag -a v2.1.0 -m "Release 2.1.0"
git push --tags

Сравнение с Gitflow

Критерий TBD Gitflow
Количество веток 1 + короткие feature develop, main, release, hotfix, feature
Время жизни ветки 1-2 дня Недели и месяцы
Интеграция Непрерывная По релизным окнам
Feature flags Обязательны Не нужны
CI/CD Обязателен Желателен

Частые ошибки

  • Не использовать Feature Flags — без флагов короткие ветки не помогают при длинной разработке фич
  • Игнорировать CI — TBD без автоматических тестов — это просто частые коммиты в сломанный main
  • Слишком большие PR даже при TBD — разбивай задачи на маленькие инкременты (< 400 строк в PR)
  • Переходить на TBD без подготовки команды — нужны зрелый CI/CD, культура код-ревью и Feature Flag система

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

Ресурсы