Короткоживущие ветки против gitflow

Команда читает «trunk-based development» и слышит «коммить прямо в main, без веток, без PR». Они отключают защиту веток. За неделю trunk краснеет дважды в день, незапрошенное изменение утекает с кредами, и они заключают, что trunk-based «не масштабируется». Они выбросили не то. Trunk-based никогда не был про удаление веток — он про то, чтобы держать их настолько короткоживущими, чтобы они не накапливали разрыв. Ветка живёт час, за зелёным гейтом и ревью, а потом её нет.

Что на самом деле задаёт «короткоживущая»

Определение trunk-based от DORA конкретно, а не «по ощущениям». Держите три или меньше активных веток в репозитории в любой момент. Ветки должны жить не более одного дня до слияния в trunk — часто всего несколько часов. Нет заморозок кода и нет фаз интеграции. Каждая ветка — это одно малое, узкое изменение, которое открывает PR, проходит быстрый CI-гейт, получает быстрое ревью и мёржится в тот же день. Ветка — это зона ожидания для ревью и гейтинга, а не место, где работа живёт.

Иногда это запускают как чистый «коммит в trunk» (вообще без веток, частое в малых co-located командах с парным программированием), а чаще как «короткоживущие feature-ветки» (версия, которую использует большинство, потому что она сохраняет код-ревью и PR-гейт). Обе — trunk-based. Разделительная черта не «ветка или не ветка» — это время жизни. Ветка, живущая часы, — trunk-based; ветка feature/*, живущая две недели, — это долгоживущая ветка, ради устранения которой существует практика, как бы вы ни называли свой workflow.

Почему gitflow оптимизирован под противоположный мир

Gitflow даёт вам постоянные ветки main и develop, плюс ветки feature/*, release/* и hotfix/* с формальными фазами: фичи интегрируются в develop, ветка release стабилизируется, затем мёржится в main и тегается. Это связная модель — для мира, под который она была спроектирована: «коробочный», версионированный софт с плановыми релизами, несколько поддерживаемых в поле версий и без непрерывного развёртывания. В том мире явная фаза стабилизации и параллельные релизные линии оправдывают себя.

Для непрерывно развёртываемого веб-сервиса gitflow институционализирует ровно тот разрыв, о котором предупреждал прошлый урок. Долгоживущие ветки feature/* накапливают расхождение; продвижение develop-в-release-в-main — это встроенная фаза интеграции; «готовые» фичи лежат в develop и гниют, пока ждут следующего релизного поезда. Вы наследуете big-bang слияния и заморозки кода по дизайну. Исследование DORA явно отмечает фазы интеграции и заморозки кода как анти-паттерны для производительности доставки — gitflow делает их несущими.

Релизить без долгоживущих веток

Возражение: «если есть только trunk, откуда берутся релизы, и как мне пропатчить старую версию?» У trunk-based есть конкретный ответ — ветка для релиза, а не для фичи. Когда вы нарезаете релиз, вы создаёте короткоживущую ветку release/x.y от trunk на этом коммите. Повседневная разработка на ней никогда не идёт. Если нужен критический фикс, вы чините его сначала на trunk (чтобы следующий релиз тоже его имел) и cherry-pick-аете единственный коммит на release-ветку. Release-ветка — это read-mostly снимок, а не параллельная линия разработки, так что она никогда не накапливает разрыв. Команды на непрерывном деплое часто пропускают даже это и просто тегают trunk.

Для больших изменений, которые действительно нельзя выкатить за день — замена ORM, смена платёжного провайдера — инструмент trunk-based — это branch by abstraction, а не долгоживущая ветка. Вы вводите слой абстракции над тем, что заменяете, инкрементально строите новую реализацию за ним на trunk (каждый шаг мёржится ежедневно, тёмный, пока не готов), переключаете абстракцию на новую реализацию, затем удаляете старую и саму абстракцию. Большой рефакторинг всё это время живёт на trunk как последовательность малых зелёных коммитов — никогда как трёхнедельная ветка.