# Trunk-based development: щоденні мерджі в main простими словами для продактів

> Trunk-based development простими словами: чому команди щодня мерджать маленькі зміни в main, що для цього потрібно і що це означає для продакта.

- Джерело: https://productovi.com/uk/blog/trunk-based-development
- Автор: Sergey Bruh
- Опубліковано: 2026-10-02
- Теми: Гілки, GitHub flow, Релізи, теги та версії

**Trunk-based development — це спосіб роботи, за якого кожен розробник щонайменше раз на день мерджить маленькі зміни в одну спільну гілку — стовбур, зазвичай `main`, — а все недописане ховає за feature flag.** Фічевих гілок, які живуть тижнями, тут немає: гілка живе кілька годин, від сили день. Сенс у тому, щоб уся команда постійно працювала на одному коді, а кожна зміна була достатньо маленькою, щоб її можна було швидко переглянути, протестувати й викласти.

## Єдине правило, яке все тримає

Уся модель тримається на одному правилі: **мерджити в стовбур щонайменше раз на робочий день.** «Стовбур» (trunk) — це давня назва головної гілки дерева, і в Git вона означає головну гілку — ту, що називається `main` (або `master` у старіших репозиторіях). Усе інше відгалужується від неї й швидко в неї повертається.

Протилежність — це «довгоживуча фічева гілка»: гілка, яка живе тиждень або довше, поки хтось наодинці будує фічу, а потім одним махом вливає величезну купу змін. Trunk-based development існує, щоб ця купа була якнайменшою. Замість одного великого мерджу наприкінці тижня ви отримуєте багато крихітних мерджів щодня.

## Як виглядає робочий день

Розробник бере маленький, самодостатній шматок роботи, а не цілу фічу. Він відгалужується від `main`, робить два-три коміти, за кілька годин відкриває pull request, і того ж дня його переглядають і мерджать. Якщо фіча готова лише наполовину, готові частини все одно мерджать — але за **feature flag**, тобто перемикачем, який вмикає чи вимикає цю частину продукту без нового деплою.

Для дрібної правки в один рядок багато команд узагалі не заводять гілку: комітять одразу в `main`, бо таку маленьку зміну легко перевірити на місці й так само легко відкотити, якщо вона щось зламала.

Ритм, який варто запам'ятати: маленька гілка, швидке рев'ю, мердж, деплой — і так по колу.

![Цикл trunk-based development: маленька гілка, рев'ю, мердж у main, деплой, повтор (інфографіка англійською)](/blog/trunk-based-development/cycle.png)

## Навіщо команди так працюють

1. **Майже зникають конфлікти при мерджі.** Конфлікт виникає, коли двоє людей змінили ті самі рядки. Малі й часті мерджі означають, що зміни майже не перетинаються, а якщо й перетинаються — конфлікт на кілька рядків, а не на кілька сотень.
2. **Рев'ю стає швидким і чесним.** Переглянути зміну на 30 рядків легко; переглянути зміну на 3 000 рядків — це переглянути по діагоналі й щось пропустити. Малі зміни перевіряють по-справжньому.
3. **Стовбур завжди майже готовий до релізу.** Оскільки `main` щодня отримує протестовану роботу, команда може викласти його майже будь-якої миті. Немає «тижня стабілізації», коли все завмирає.
4. **Стає можливою безперервна доставка.** Коли кожен мердж маленький і протестований, викласти його автоматично — це маленький крок, а не стрибок у невідоме. Команди, які деплоять багато разів на день, майже завжди trunk-based.

![Чотири переваги trunk-based development: менше конфліктів, швидші рев'ю, main завжди майже на проді, безперервна доставка (інфографіка англійською)](/blog/trunk-based-development/benefits.png)

## Чого це коштує

Нічого з цього не дається безкоштовно. Trunk-based development працює лише тоді, коли команда спершу побудувала страховку:

- **Автоматичні тести, які ганяються на кожній зміні.** Якщо зламана зміна може дістатися `main`, модель розвалюється, бо всі будують на цій спільній лінії. Тести — це підлога під ногами кожного.
- **Feature flags, і дисципліна їх використання.** Недописане треба ховати охайно, інакше команда знову чекатиме на «великий мердж».
- **Пайплайн, який швидко деплоїть і швидко відкочує.** Швидке викладання безпечне лише тоді, коли невдалий реліз можна скасувати за хвилини.
- **Культура маленьких pull request.** Це найважче. Доводиться різати роботу на шматки, які можна переглянути за один раз, і це навичка, яку команда має тренувати.

Компроміс реальний: trunk-based development — найкраща модель для продуктів, що викладаються безперервно: сайтів, вебзастосунків, API, внутрішніх інструментів. Вона погано пасує софту, який випускається номерними версіями і який люди встановлюють, наприклад мобільним застосункам, що проходять перевірку в магазинах. Такі команди зазвичай обирають [git flow](/uk/blog/github-flow-vs-git-flow), де реліз є свідомою подією, а не безперервним потоком.

## Trunk-based development проти GitHub flow проти git flow

Trunk-based development — найсуворіший із трьох:

| Модель                  | Як часто робота мерджиться в `main` | Довгоживучі гілки        |
| ----------------------- | ----------------------------------- | ------------------------ |
| Git flow                | За графіком релізів                 | Дві (`main` і `develop`) |
| GitHub flow             | Коли кожна зміна готова             | Одна (`main`)            |
| Trunk-based development | Щонайменше раз на день              | Жодної                   |

GitHub flow уже каже «мердж у `main`, коли готово, і одразу деплой». Trunk-based development затягує це до «мердж щонайменше щодня, а недописане ховай за флагами». Повне порівняння GitHub flow і git flow — у статті [GitHub flow чи git flow](/uk/blog/github-flow-vs-git-flow).

## Що це означає для продакта

Якщо ваша команда працює trunk-based, у тому, як ви читаєте її апдейти, змінюються три речі:

1. **«Змерджено» й далі означає «скоро на сайті»** — як у GitHub flow, але ще більшою мірою, бо мерджі відбуваються щодня, а деплой іде автоматично. Не пишіть анонс для фічі одразу після мерджу — спершу перевірте, чи вона за флагом.
2. **Feature flags — ваш найкращий друг.** Фіча може бути «готова» і змерджена, але невидима для користувачів. Запитуйте «вона за флагом, і коли піде на 100%?» замість «коли вона запуститься?».
3. **Моменту релізу немає.** Фічі просочуються безперервно. Маркетингові плани, збудовані навколо гучного анонсу нової великої версії, доведеться перебудувати навколо менших, поступових оновлень — або навколо моменту, коли вмикають флаг.

Trunk-based development змінює й розмову про ризики. Замість «чи запрацює цей реліз?» питання стає «якщо ця маленька зміна помилкова, як швидко ми це помітимо й відкотимо?».

Якщо Git для вас узагалі новий, почніть зі статті [Git для продакт-менеджерів](/uk/blog/git-for-product-managers) або одразу з безкоштовного уроку про [GitHub flow](/uk/courses/git-for-product/github-flow/theory) та уроку про [гілки](/uk/courses/git-for-product/branches/theory).

## Ключові висновки

- **Trunk-based development = мердж у `main` щонайменше раз на день**, з маленькими короткоживучими гілками й feature flags для всього недописаного.
- Працює це тому, що малі мерджі означають менше конфліктів, швидше рев'ю і стовбур, який завжди майже готовий до релізу.
- Потребує автоматичних тестів, feature flags, швидких деплоїв і культури маленьких pull request — страховка будується першою.
- Пасує продуктам із безперервним деплоєм (веб, API, внутрішні інструменти), а не номерному софту на кшталт мобільних застосунків.
- Для продакта «змерджено» означає «скоро на сайті», фічі виходять за флагами, а єдиного моменту релізу не існує.

## FAQ

### Trunk-based development — це те саме, що GitHub flow?

Не зовсім. GitHub flow мерджить кожну зміну в `main`, коли вона готова; trunk-based development додає щоденний мінімум і скорочує життя гілок до годин. Можна вважати trunk-based development логічним продовженням GitHub flow. Повна картина — у [GitHub flow чи git flow](/uk/blog/github-flow-vs-git-flow).

### Чи потрібні feature flags для trunk-based development?

Так, на практиці — так. Правило щоденного мерджу працює лише тоді, коли напівготова робота може безпечно лежати в `main`, не доходячи до користувачів, і feature flag — стандартний спосіб цього досягти. Без флагів команда скочується назад до довгоживучих гілок, і модель перестає бути trunk-based.

### Навіщо мерджити щонайменше раз на день?

Бо вартість мерджу зростає з часом. Гілка, змерджена щодня, мало перетинається з іншими, тож конфлікти лишаються малими, а рев'ю — легкими. Гілка, змерджена раз на тиждень, устигла розійтися з рештою команди — це і є той болісний «великий мердж», якого модель існує, щоб уникнути.

### Чи працює trunk-based development для мобільних застосунків?

Зазвичай ні. Мобільні застосунки виходять номерними версіями через перевірку в магазинах, тож реліз — це подія, і оновити всіх користувачів миттєво неможливо. Такі команди зазвичай обирають git flow. Trunk-based development розкривається на продуктах, що деплояться безперервно з `main`.

## Пов’язані уроки

- [GitHub flow: малі гілки, швидкі мерджі](https://productovi.com/uk/courses/git-for-product/github-flow.md)
- [Гілки в Git: паралельні версії проєкту](https://productovi.com/uk/courses/git-for-product/branches.md)
- [Злиття (git merge): мердж-коміт, squash і rebase на GitHub](https://productovi.com/uk/courses/git-for-product/merging.md)
- [Релізи на GitHub і версії: теги, SemVer, changelog](https://productovi.com/uk/courses/git-for-product/releases-and-versions.md)
- [Перша зміна в браузері і як її відкотити через revert](https://productovi.com/uk/courses/git-for-product/first-change-in-the-browser.md)