Как работает trunk-based development?

Trunk-based development (TBD) — это стратегия ветвления, при которой команда поддерживает одну главную ветку (trunk, обычно main или master) и вливает в неё изменения очень часто. Вместо того чтобы неделями разрабатывать фичу в отдельной ветке, разработчик создаёт короткоживущую ветку, делает небольшое изменение и быстро сливает её обратно в trunk.

Ключевые принципы

• Одна долгоживущая ветка — trunk.
• Короткоживущие ветки (менее 1–2 дней) или прямые коммиты в trunk.
• Частая интеграция: минимум раз в день.
• Незавершённый код скрывается за feature-флагами.
• Автоматические тесты и CI обязательны.

Как это работает на практике

Разработчик берёт задачу, создаёт ветку от trunk, пишет небольшой кусок кода и открывает pull request. После ревью и прохождения CI ветка сливается в trunk. Если функционал ещё не готов к релизу, он оборачивается в feature-флаг и остаётся выключенным в продакшене.

git checkout main
git pull
git checkout -b short-feature
git commit -m "add small change"
git push origin short-feature
# после ревью и CI
git checkout main
git merge short-feature
git push origin main

Feature-флаги

Feature-флаг — это условие в коде, которое включает или выключает функционал без деплоя новой версии. Это позволяет мержить недоделанный код в trunk, не ломая продакшен.

if (featureFlags.newCheckout) {
  renderNewCheckout();
} else {
  renderOldCheckout();
}

Преимущества и требования

• Меньше merge-конфликтов и проще ревью.
• Быстрая обратная связь от CI.
• Готовность к непрерывному деплою.
• Требует дисциплины, автотестов и feature-флагов.

Trunk-based development хорошо подходит командам с сильным CI/CD и практикой непрерывной поставки. Если у вас нет автоматических тестов и культура ревью слабая, переход к TBD может быть болезненным.