Если вы хоть раз застревали в бесконечных конфликтах при слиянии веток, вы знаете это чувство: код вроде работает, но Git превращается в поле боя. Так вот, есть подход, который практически устраняет эту боль. Он называется Trunk-Based Development (разработка на основе ствола) — и да, это не модный хайп, а практика, на которой уже десятилетиями живут крупнейшие IT-компании.
Что такое Trunk-Based Development и в чем суть
Если коротко: вся команда коммитит в одну главную ветку — main (раньше называли master, ещё раньше — trunk).
Без долгоживущих feature-веток.
Без параллельных “develop”, “release”, “hotfix”.
Без веток, которые живут месяцами и превращаются в минное поле.
Схема выглядит так:
🌳 Все разработчики регулярно (в идеале — несколько раз в день) вливают изменения в main
🔁 Короткие ветки допускаются — но только для код-ревью и сразу удаляются
🚫 Долгоживущие ветки — табу
⚙️ Перед коммитом — полный локальный прогон сборки и тестов
🤖 После коммита — автоматическая проверка CI
Это и есть настоящий фундамент Continuous Integration. Не декларативный, а реальный.
Почему GitFlow устаревает
Когда-то GitFlow казался вершиной инженерной культуры. Четкая структура, разделение ролей веток, контроль релизов. Но в реальности он часто создает:
💥 накопленные конфликты
🐢 замедление интеграции
🧩 расхождение кодовой базы
😵 “merge hell - ад слияний” перед релизом
Проблема не в GitFlow как таковом. Проблема в том, что он предполагает, что изоляция — это благо. А в реальности изоляция кода в долгих ветках приводит к рассинхронизации команды.
Trunk-Based Development исходит из другой философии:
Интегрируйся рано. Интегрируйся часто. Никогда не отрывайся надолго.
И это не теория. Google и Facebook (ныне Meta) работают именно так. У Google — десятки тысяч разработчиков в одном монорепозитории. И они не разваливаются под нагрузкой.
Как это вообще работает при тысячах разработчиков?
Вот тут начинается самое интересное.
Секрет не в магии, а в дисциплине и инструментах:
⚙️ Feature flags — функциональность скрыта флагами, код уже в main, но поведение выключено
🧠 Branch by Abstraction — архитектурные изменения внедряются через промежуточные слои
🚦 “Don’t break the build” — ломать сборку запрещено культурно и технически
🧪 Жесткий автоматический CI после каждого коммита
📦 Возможность релизиться прямо из main
Feature flags радикально меняют правила игры. Вы можете закоммитить недоделанную фичу, но пользователи её не увидят. Это снимает страх “недописанного кода”.
А Branch by Abstraction позволяет переписывать крупные части системы без массивных веток на полгода.
Это уже не просто техника — это зрелая инженерная культура.
Continuous Integration и Continuous Delivery — без самообмана
Многие команды говорят: “У нас CI/CD”.
Но при этом:
🕒 разработчики интегрируются раз в неделю
📂 живут 5–6 параллельных веток
🔥 перед релизом начинается ручная магия
Это не CI. Это имитация.
Настоящий Continuous Integration — это когда каждый разработчик вливает изменения минимум раз в 24 часа. В идеале — чаще.
Trunk-Based Development делает это естественным требованием. Если ты не интегрируешься, ты просто выпадаешь из ритма команды.
И вот здесь появляется важный эффект:
📈 кодовая база всегда в состоянии “готово к релизу”
📉 риск больших конфликтов падает почти до нуля
🚀 релизы становятся рутинной операцией
Это фундамент Continuous Delivery. Не дополнительная опция, а логическое продолжение.
Маленькие команды vs большие организации
Есть распространённый миф: “Это работает только в Google”.
На самом деле:
👨💻 В маленькой команде можно коммитить прямо в main
🔍 В средней — через Pull Request, но ветки живут часы, максимум день
🏢 В большой — добавляется строгий CI и масштабируемая инфраструктура
Граница между “малой” и “масштабной” моделью определяется не числом людей, а скоростью коммитов.
Интересный момент: команды могут свободно “растягиваться” и “сжиматься”, не меняя модель работы. Это очень важно для стартапов и продуктовых команд, которые быстро растут.
Личное мнение: это про культуру, а не про Git
Самое важное в этой истории — это не ветки.
Это про мышление.
GitFlow — это философия контроля.
Trunk-Based Development — философия постоянной синхронизации.
В первом случае мы изолируемся, чтобы “сделать красиво”.
Во втором — интегрируемся, чтобы не потерять скорость.
Да, такой подход требует:
💬 активного общения
🧪 сильной тестовой культуры
🤖 надежного CI
🧠 зрелых инженеров
Но именно поэтому он и работает на масштабе.
И да, переход на trunk-based — это почти всегда культурный шок. Люди боятся коммитить часто. Боятся “засорить main”. Боятся недоделанного кода.
Но страхи исчезают, когда:
🔒 есть feature flags
🔁 есть быстрый CI
📊 есть прозрачность изменений
В итоге команда начинает двигаться быстрее — без ощущения хаоса.
Что будет дальше
Я убежден, что через несколько лет Trunk-Based Development станет стандартом де-факто. Уже сейчас книги вроде Continuous Delivery и The DevOps Handbook продвигают именно эту модель.
GitFlow не исчезнет — он останется удобным для определённых сценариев, особенно в проектах с редкими релизами.
Но для продуктовой разработки, SaaS, команд с высокой пропускной способностью — trunk уже победил.
И если вы сейчас находитесь в состоянии “каждый релиз — это стресс”, возможно, проблема не в людях.
Возможно, проблема в ветках.
Источники
- Оригинальная статья о Trunk-Based Development:
https://trunkbaseddevelopment.com/ - Полный разбор и объяснение (Telegra.ph):
https://telegra.ph/Zabudte-o-GitFlow-pochemu-razrabotka-na-osnove-stvola--novyj-standart-dlya-bystryh-komand-02-21