GitHub flow: малі гілки, швидкі мерджі

GitHub flow це короткий цикл навколо одного правила: main завжди версія, яку можна хоч зараз викласти на сайт. Кожна зміна проходить той самий шлях:

1. Створити короткоживучу гілку зі свіжої main: git switch -c fix/footer-links main.
2. Закомітити зміну й зробити пуш: git push -u origin fix/footer-links.
3. Відкрити pull request у main (gh pr create --base main).
4. Рев'юери схвалюють, обов'язкові перевірки проходять.
5. Мердж, у Котокорму через Squash and merge (gh pr merge --squash --delete-branch).
6. Деплой викладає нову main на живий сайт.
7. Перевірити зміну на живому сайті власними очима.

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

У Котокорму тексти від Emma, поріг безкоштовної доставки від Daniel і виправлення кнопки пройшли цей шлях за тиждень або швидше. Три короткі гілки, три squash-коміти в main, і кожен на сайті за кілька хвилин після мерджу.

«Змерджено» і «викладено» це дві події. Мердж змінює main у репозиторії. Деплой (deploy) бере цю main, збирає сайт і викладає його на сервери, якими користуються клієнти. У Котокорму деплой це процес GitHub Actions, завдання на кшталт build і test, тільки воно запускається на main після кожного мерджу. Між ними кілька хвилин, і друге йде за першим саме. В інших командах між ними можуть бути дні чи тижні.

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

Перевірити можна, нікого не питаючи. Станом на 2026 рік на сторінці репозиторію в правій колонці є розділ Deployments; натисни production, щоб побачити, який коміт зараз на сайті і відколи. У терміналі gh run list --branch main показує останні запуски процесів на main, зокрема деплої.

Перш ніж казати підтримці, що щось уже на сайті, зроби обидві речі: перевір production у Deployments, а тоді глянь на живий сайт. Деплой каже, що код прибув; власні очі кажуть, що він працює.

Буває, що мердж проходить, а деплой ні. Тоді зміна є в main, але не на сайті: клієнти й далі бачать попередню версію, ту, яку виклав останній успішний деплой. Нічого не встановлено наполовину; нова версія просто не прибула.

Команда отримує сповіщення, і має два виходи:

• Виправити вперед: маленький pull request, який лагодить те, що зламало деплой, і швидкий мердж.
• Відкотити (revert): скасувати мердж. Кнопка Revert на змердженому pull request відкриває новий pull request, який прибирає саме цю зміну; у терміналі те саме робить git revert із хешем коміту.

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

Для PM упалий деплой ще одна причина розрізняти «змерджено» і «на сайті». Якщо колега питає про змерджену зміну, а останній запуск у Deployments упав, чесна відповідь: «змерджено, на сайті ще немає, команда вже розбирається».

Зібрати всю фічу в одній гілці й змерджити її раз наприкінці звучить охайно. На практиці це закінчується як feature/loyalty-points у Котокорму: дванадцять комітів попереду, 86 позаду, п'ять місяців ніхто не чіпав.

Малі pull requests у короткоживучих гілках безпечніші з трьох причин:

• Менше відставання. Кожен день життя гілки main іде вперед без неї. Що більше відставання, то більше конфліктів і несподіванок, коли стара робота зустрічає новий код.
• Краще рев'ю. Сорок змінених рядків це десять уважних хвилин. Дві тисячі чекають на чийсь вільний вечір, а тоді їх проглядають навскоси.
• Точний відкат. Якщо одна мала зміна щось зламала, revert прибирає саме її. Відкотиш величезну, і разом із поганою зміною підуть десять добрих.

Тож малість не про охайність, а про менший ризик на кожен мердж. Просте правило багатьох команд: гілка живе кілька днів, а pull request можна переглянути за один підхід. GitHub не обмежує розмір і не дає малим pull requests пільг у правилах рев'ю; користь лише в тому, наскільки безпечно вони виходять.

Гілку, що прямує до проблем, можна помітити ще до рев'ю. Подивися на два числа:

• Коли її востаннє оновлювали. Гілка, якої тижнями ніхто не чіпав, або завершена й забута, або застрягла.
• Наскільки вона відстає від main. Сторінка гілок показує для кожної лічильники «behind» (позаду) і «ahead» (попереду). У терміналі git rev-list --left-right --count main...feature/wishlist друкує обидва: перше число це скільки комітів є в main, але немає в гілці (відставання), друге скільки є в гілці, але немає в main (випередження).

Стара й далеко позаду: ось тривожний знак. На графі комітів це довга смуга, що почалася високо вгорі, поки main поруч збирала коміти. Гілка, що почалася з найсвіжішої main і містить один малий коміт, протилежність: мало що переглядати й нічого не треба наздоганяти.

Pull request розповідає те саме. Якщо Files changed показує 60 файлів для «дрібної правки», спитай чому. Дружнє питання на початку дешевше за болюче рев'ю чи ризикований мердж згодом.

Фіча, завелика для одного рев'ю, не потребує однієї великої гілки. Розріж її на серію малих pull requests, кожен з яких змерджують і викладають окремо, а незавершені частини ховаються за одним фіча-флагом.

Для балів лояльності в Котокорму план нарізки може виглядати так:

1. Нараховувати бали за оплачені замовлення, зберігати, але ніде не показувати.
2. Показувати баланс в акаунті клієнта, за флагом loyalty-points.
3. Списувати бали як знижку під час оформлення, за тим самим флагом.
4. Сторінка від Emma з поясненням програми, теж за флагом.

Кожен шматок переглядають за один підхід, і він виходить на сайт непомітно. Спершу команда вмикає флаг лише для працівників і пробує все на справжньому сайті. Фічу запущено лише того дня, коли флаг вмикають для всіх клієнтів, а відкат означає його вимкнути.

Альтернатива, перебудувати все в одній довгій гілці й змерджити наприкінці, повертає всі проблеми feature/loyalty-points: відставання, рев'ю, яке неможливо закінчити, і запуск «усе або нічого».

Фіча-флаг (feature flag) це перемикач навколо частини сайту. Код є в main і викладений, але клієнти бачать цю частину, лише поки флаг увімкнено.

Це розв'язує справжню проблему з часом. Осінній розпродаж у Котокорму починається в понеділок. Змерджиш банер від контент-маркетологині Emma в п'ятницю без флагу, і він оголосить розпродаж, який ще не почався. Чекатимеш до ранку понеділка, і рев'ю, мердж і деплой стануться поспіхом, коли клієнти вже заходять.

З флагом Daniel загорнув банер у перевірку autumn-sale-banner, вимкнену за замовчуванням. Pull request #136 від Emma переглянули й змерджили в п'ятницю, і деплой виклав код на сайт. У суботу клієнт, що відкриває головну, бачить те саме, що й раніше: код на сайті, флаг вимкнено. Жодних помилок і жодного мерехтіння.

Тож із флагами в однієї зміни три стани: змерджено (у main), викладено (на серверах) і видно (увімкнено для клієнтів). Змерджений pull request із вимкненим флагом означає «готово й приховано», а не «запущено».

У Котокорму перемикачі флагів живуть у панелі налаштувань флагів поза репозиторієм. Щоб увімкнути чи вимкнути флаг, не потрібні ні pull request, ні рев'ю, ні деплой, і діє це за лічені секунди.

Це змінює сам запуск. У понеділок о 8:00 Emma вмикає autumn-sale-banner, і клієнти бачать банер майже одразу. Якщо щось не так, вона вимикає його, теж без деплою. Вимкнути флаг набагато швидше, ніж відкотити мердж.

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

Підступ: кожен флаг це зайве «якщо» в коді. Коли фічу ввімкнено назавжди, хтось має прибрати флаг малим pull request, інакше код заповниться забутими перемикачами, яких ніхто не наважується торкатися. Додай «прибрати флаг» у план із першого дня.

Коли фічу будують малими pull requests за флагом, питання «де вона?» має дві половини, і PM читає обидві.

Список pull requests показує, наскільки просунулося будівництво. Познач кожен шматок однією міткою й відфільтруй за нею: loyalty у списку або gh pr list --label loyalty --state all у терміналі. Стан кожного рядка каже етап:

• Draft: ще пишеться; змерджити поки не можна.
• Відкритий, «Review required», перевірки пройшли: зібрано й перевірено роботами, чекає на схвалення людини.
• Merged: у main і викладено, але з вимкненим флагом клієнти цього не бачать.

Флаг показує, що бачать клієнти. Вимкнено: не бачить ніхто. Увімкнено для працівників: команда тестує на справжньому сайті. Увімкнено для всіх: це і є запуск.

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