GitHub flow чи git flow: яка модель гілок пасує вашій команді і що це змінює для продакта

GitHub flow чи git flow — якщо коротко, різниця така: у GitHub flow є одна довгоживуча гілка, main, яка завжди готова до викладання, і кожна зміна потрапляє в неї через коротку гілку й pull request, а після мерджу зазвичай за кілька хвилин іде деплой. У git flow довгоживучих гілок дві: main для випущених версій і develop для наступної, плюс окремі гілки для фіч, релізів і хотфіксів, а випускають усе за графіком. GitHub flow пасує сайтам і вебзастосункам, які викладаються безперервно; git flow — продуктам, де реліз є подією: мобільним застосункам, що проходять перевірку в магазинах, або програмам, які клієнти встановлюють самі. Для продакт-менеджера найбільша різниця ховається в одному слові: у GitHub flow «змерджено» зазвичай означає «скоро на сайті», а в git flow — «у наступній версії».

Приклад: одне слово, два значення

Котокорм, інтернет-магазин кормів для тварин, працює за GitHub flow. Коли веброзробник Daniel о 9:40 змерджив через squash виправлення кнопки оформлення замовлення, автоматичний деплой виклав його на сайт о 9:44. Між «змерджено» і «на сайті» минуло чотири хвилини, і нікому не довелося нічого натискати.

На попередній роботі Daniel робив фітнес-застосунок для телефонів, і та команда працювала за git flow. Нова версія виходила раз на два тижні, і кожну спершу перевіряли Apple і Google. Коли посеред спринту змерджили нагадування про тренування, вони потрапили в develop, а не у версію, яка була в користувачів. До телефонів вони дісталися майже за два тижні. Не раз маркетинг бачив у командному чаті «нагадування змерджено» і починав готувати анонс фічі, якою ще ніхто не міг скористатися.

Та сама кнопка, те саме слово, зовсім різний зміст. Коли знаєте, за якою моделлю працює команда, ви правильно читаєте кожен статус.

GitHub flow простими словами

1. У main завжди лежить версія, яку можна викласти просто зараз.
2. Для кожної зміни від main створюють коротку гілку, наприклад fix/checkout-button.
3. У ній комітять зміну й відкривають pull request у main.
4. Рев'юери коментують і схвалюють, автоматичні перевірки проходять.
5. Pull request мерджать, гілку видаляють.
6. Нову main викладають, у багатьох командах автоматично.

Гілки живуть дні, а не тижні, а pull requests лишаються такими малими, що їх можна переглянути за один присід. Усе, що ще не готове для клієнтів, або чекає у своїй гілці, або мерджиться прихованим за фіча-флагом: перемикачем, який вмикає чи вимикає частину продукту без нового деплою.

Git flow простими словами

Git flow походить зі статті Вінсента Дріссена 2010 року «A successful Git branching model». У ньому п'ять видів гілок:

Коли в develop набирається достатньо для наступної версії, від неї «відрізають» релізну гілку, скажімо release/2.8.0. Тестувальники працюють з нею, а develop тим часом приймає фічі для наступної версії. Коли реліз готовий, релізну гілку мерджать у main, ставлять тег і мерджать назад у develop, щоб виправлення не загубилися. Хотфікс проходить той самий подвійний шлях: у main з новим тегом, наприклад v2.7.1, і в develop (або у відкриту релізну гілку, якщо така є). Забудьте другий мердж — і наступна версія поверне баг.

GitHub flow чи git flow: порівняння

Де тут trunk-based development

Є й третя модель, про яку ви почуєте. У trunk-based development (розробці в основній гілці) усі мерджать малі зміни в main щонайменше раз на день, гілки живуть години, а не дні, а фіча-флаги ховають усе, що не готове. Це GitHub flow, доведений до краю: ще швидше, але безпечно лише з дуже добрими автоматичними тестами й сильною дисципліною команди.

У 2020 році Дріссен додав до власної статті примітку: для вебзастосунків, які викладаються безперервно, він радив простіший підхід на кшталт GitHub flow, а git flow лишав для програм з явними версіями. Багато вебкоманд саме так і зробили.

Яка модель пасує вашому продукту

Git flow зазвичай доречний, коли:

• реліз має пройти чужу перевірку, як у магазинах застосунків;
• клієнти самі встановлюють і оновлюють програму, тож одночасно живе кілька версій;
• ви підтримуєте старі версії виправленнями, наприклад для корпоративних клієнтів;
• релізи узгоджують з маркетингом, юристами чи партнерами на фіксовану дату.

GitHub flow зазвичай доречний, коли:

• у продукті завжди лише одна жива версія, як на сайті;
• команда може викладатися багато разів на день і має безпечний шлях назад (revert чи флаг);
• ви хочете отримувати відгук від справжніх користувачів, щойно кожна мала зміна готова.

Вебкоманда, яка переходить на git flow, здебільшого отримує очікування й подвійні мерджі. Мобільна команда без релізних гілок не має де стабілізувати версію, поки нова робота все надходить. А номери версій не вимагають git flow: команда на GitHub flow може щотижня ставити тег релізу поверх безперервних деплоїв.

Як зрозуміти, яку модель використовує репозиторій

Відкрийте сторінку гілок репозиторію і пошукайте три ознаки:

• Гілка за замовчуванням. Якщо це develop, нові pull requests за замовчуванням ідуть туди: git flow.
• Назви гілок. release/… і hotfix/… поруч із develop означають git flow. Лише main і кілька свіжих гілок fix/…, feature/… чи content/… означають GitHub flow. Назви гілок — звичка команди, а не правило Git, тож це сильна підказка, а не доказ.
• Куди йдуть pull requests. Змерджений pull request показує, у яку гілку його злили. «Змерджено в develop» означає, що зміна чекає на реліз.

Ось такий список гілок — git flow як із підручника:

develop          Default · updated today
main             Updated 9 days ago · tag v2.8.0
release/2.9.0    Updated yesterday
feature/step-goals   Updated 2 hours ago · pull request into develop
hotfix/2.8.1     Updated 1 hour ago · pull request into main

Гілка за замовчуванням тут develop, main оновлювалася дев'ять днів тому разом із тегом останньої версії, а релізна й хотфікс-гілки відкриті одночасно.

Якщо ж main майже єдина гілка, гілки живуть години, а код повний флагів, перед вами trunk-based development. Коли маєте сумнів, поставте одному розробнику одне питання: «Як у нас змерджена зміна доходить до клієнтів?»

Що це змінює для продакта

Відповідь на «це вже на сайті?». У GitHub flow перевірте, що pull request змерджено в main і деплой після нього завершився; у багатьох репозиторіях це видно в розділі Deployments («деплої») на сторінці репозиторію (станом на 2026 рік). Потім перевірте, чи не ховає зміну фіча-флаг. У git flow питання звучить інакше: «У якій це версії і чи дійшла та версія до користувачів?»

Планування. Git flow дає календар, і дата відрізання релізу стає найспірнішою датою кожного циклу: фіча, змерджена на день пізніше, чекає на наступний потяг. GitHub flow дає потік: плануйте малими шматками, кожен з яких може вийти сам по собі, а коли клієнти їх побачать, вирішуйте флагами.

Анонси. У git flow ніколи не анонсуйте за словом «змерджено». У GitHub flow, якщо є флаг, анонсуйте, коли флаг увімкнено, а не коли зміну змерджено.

Рев'ю. Безпечним GitHub flow роблять саме малі pull requests. Якщо «дрібна правка» зачіпає шістдесят файлів, спитайте чому; як робити таке рев'ю, розповідає стаття Як робити рев'ю pull request.

Типові помилки

Переходити на git flow заради «нормальних релізів». Зазвичай насправді хочуть знати, що і коли змінилося. Це дають теги версій і нотатки до релізів, без жодної develop.

Довгоживучі гілки в GitHub flow. Гілка фічі, яку місяцями не чіпали і яка відстає від main на десятки комітів, — це GitHub flow лише за назвою. Краще перебудувати фічу малими pull requests за флагом, ніж мерджити все одним махом.

Забувати прибирати флаги. Кожен флаг — це додаткове «якщо» в коді. Коли фічу увімкнено назавжди, флаг треба прибрати.

Що зробити цього тижня

1. Відкрийте репозиторій свого продукту й подивіться на гілку за замовчуванням і назви гілок.
2. Перегляньте три останні змерджені pull requests: у яку гілку їх злили?
3. Спитайте розробника, як і коли змерджена зміна доходить до клієнтів і чи користується команда фіча-флагами.
4. Запишіть відповідь одним реченням для колег з маркетингу й підтримки.

Головне

• GitHub flow: одна довгоживуча main, короткі гілки, pull requests, деплой після мерджу.
• Git flow: main плюс develop, гілки для фіч, релізів і хотфіксів і календар релізів.
• GitHub flow пасує безперервним деплоям вебпродуктів; git flow — релізам за графіком і з версіями.
• Trunk-based development — найшвидший край шкали, і він тримається на флагах і тестах.
• Для продакта модель визначає, що означає «змерджено». З'ясуйте це до будь-якого анонсу.

FAQ

Git flow застарів?

Не для кожного продукту. Він і далі пасує мобільним застосункам, встановлюваним програмам і командам, які підтримують кілька версій. Для вебпродуктів з безперервними деплоями більшість команд обирає GitHub flow або trunk-based development, і автор моделі у 2020 році сказав приблизно те саме.

Чи є в GitHub flow версії й релізи?

Вони не обов'язкові, але їх можна додати. Команда може викладати кожен мердж і водночас щотижня ставити тег версії й публікувати нотатки до релізу, щоб усі могли сказати «виправлено у 1.4.1».

Чи можна поєднувати дві моделі?

Так, і багато хто так робить: щодня GitHub flow, а коли великий запуск потребує кількох днів стабілізації, з'являється короткоживуча релізна гілка. Головне, щоб усі знали, з якої гілки працює те, що бачать клієнти.

Що означає «змерджено в develop» для моєї фічі?

Що її завершено й прийнято до наступної версії, але користувачі її ще не мають. До них вона дійде, коли реліз з нею відріжуть, протестують, змерджать у main і випустять.

Спробуйте на практиці

Урок GitHub flow: малі гілки, швидкі мерджі простежує зміни в Котокормі від гілки до деплою, зокрема банер розпродажу, змерджений за фіча-флагом. Git flow: гілки develop, release і hotfix читає історію мобільної команди доріжка за доріжкою, а Гілки: паралельні версії проєкту пояснює, що таке гілка і як читати «ahead» і «behind». Усі три уроки входять до безкоштовного курсу Git і GitHub для продактів.