Trunk-based development

Все интегрируют в один trunk — main — непрерывно, много раз в день. Непрерывная интеграция в исходном, буквальном смысле означает именно это: каждый разработчик сливает свою работу в общий trunk минимум раз в день, часто несколько раз. Trunk — единственный источник истины, а разрыв между «код написан» и «код на trunk» измеряется часами. Причина математическая: расхождение между веткой и trunk растёт со временем, поэтому, если каждое изменение интегрируется за часы, расхождение — а значит, и конфликты слияния — остаётся крошечным. TBD бьёт по аду слияний в корне, вообще не давая двум линиям работы разойтись.

Работа происходит в очень короткоживущих ветках или небольших прямых коммитах. Ветки в TBD живут часы, редко больше дня. Многие команды используют ветку ровно столько, чтобы прогнать CI и получить быстрое ревью PR:

git checkout main
git pull
git checkout -b fix-rate-limit-header
# одно небольшое, сфокусированное изменение ...
git push -u origin fix-rate-limit-header
# быстрое ревью + зелёный CI, слияние в тот же день, удаление ветки

Меньшие организации, практикующие TBD, иногда коммитят прямо в trunk для тривиальных изменений (с CI, гейтящим пуш). Так или иначе, единица работы — маленькая: изменение, которое можно закончить, отревьюить и интегрировать в тот же день. Большие фичи делают не на больших ветках — их разбивают на маленькие инкременты, каждый из которых приземляется на trunk.

Незавершённые фичи слиты, но спрятаны за feature-флагами. Это несущая идея. Если фича занимает три недели, ты не держишь трёхнедельную ветку — ты сливаешь её наполовину готовый код в trunk непрерывно, завернув в feature-флаг, выключенный в продакшене:

if (flags.enabled("new-checkout")) {
  return renderNewCheckout();
}
return renderLegacyCheckout();

Незавершённый код на trunk (интегрирован, скомпилирован, протестирован против чужих изменений), но невидим пользователям, пока флаг не включат — что может быть постепенной выкаткой на 1%, потом 10%, потом всех. Флаги — это то, что делает «сливай постоянно, даже незавершённую работу» безопасным. Без них TBD невозможен; с ними длина ветки падает почти до нуля, а незавершённость живёт в конфигурации, а не в топологии git.

Версионные релизы рождаются из релизных веток, нарезанных от trunk — и только от trunk. TBD не запрещает версионирование; он запрещает долгоживущие ветки разработки. Когда нужно отгрузить версионный релиз, ты нарезаешь короткую релизную ветку из trunk на выбранном коммите, стабилизируешь, тегируешь и отгружаешь — но разработка никогда не переезжает на эту ветку:

git checkout main
git checkout -b release/2.4
git tag -a v2.4.0 -m "Release 2.4.0"
# критические правки cherry-pick'ятся ИЗ trunk В релизную ветку

Ключевая дисциплина: правки делаются сначала на trunk, затем cherry-pick’ятся в релизную ветку, никогда наоборот. Релизная ветка — это в основном read-only снимок для отгрузки и патчинга конкретной версии; вся настоящая работа остаётся на одном trunk. Так TBD поддерживает версионные продукты без расхождения, которое потопило develop git-flow.