Стратегії гілкування Git (Git Flow, GitHub Flow)?

Git~4 хв читання

Стратегії гілкування Git (branching strategies) визначають правила створення, злиття та видалення гілок, щоб команда координувала розробку без поломок у продакшені.

Теорія

TL;DR

Git Flow: конвеєр на заводі з окремими станціями для функцій, тестування та виправлень. GitHub Flow: фуд-трак, де готують і одразу подають.
Головне розходження: Git Flow тримає довгоживучу гілку develop як точку інтеграції перед продакшеном. GitHub Flow не має develop і зливає напряму в main.
Заплановані версійні релізи (десктоп, гра)? Git Flow. Безперервний деплой вебзастосунку? GitHub Flow.
Команда 10+ з квартальними релізами: Git Flow. Команда 1-10 з щоденними деплоями: GitHub Flow.

Швидкий приклад

bash

# GitHub Flow: один короткий цикл, main залишається deployable
git checkout main
git pull origin main                   # завжди стартуй з актуального стану
git checkout -b feature/user-login    # короткоживуча гілка
git add . && git commit -m "Add login form"
git push origin feature/user-login
# відкрити PR, ревʼю, злити в main, видалити гілку
git branch -d feature/user-login
# main готова до деплою прямо зараз

Одна гілка. Один PR. Main отримала зміни і готова до деплою в той самий день.

Git Flow тримає гілку develop як постійну точку інтеграції. Функції потрапляють спочатку в develop. Потім гілка release/* готує продакшн-код. Лише після цього main отримує версійний тег, наприклад v1.2. GitHub Flow прибирає develop повністю: гілкуєшся від main, відкриваєш PR, зливаєш назад у main після апруву. Ось і вся структурна різниця. Git Flow важчий, але передбачуваний для команд з фіксованими датами релізів. GitHub Flow швидший для тих, хто деплоїть після кожного ревʼю.

Коли що застосовувати

Мобільні або десктопні застосунки з квартальними релізами: Git Flow чисто вирішує версіонування.
Вебзастосунки або SaaS з щоденними деплоями: GitHub Flow знімає накладні витрати на гілки.
Соло або маленькі команди (1-5 осіб): GitHub Flow, без зайвого процесу.
Великі компанії з комплаєнс-аудитами: Git Flow дає чіткий поділ між продакшном і стейджингом.
Монорепозиторії з мікросервісами: GitHub Flow з тегами і вибірковими CI-задачами на сервіс.

Таблиця порівняння

Аспект	Git Flow	GitHub Flow
Гілки	main, develop, feature/, release/, hotfix/*	main, feature/* (короткоживучі)
Цикл релізів	Заплановані (v1.2 через release-гілку)	Безперервні (злиття в main = деплой)
Розмір команди	Середня-велика (10+ дев)	Мала-agile (1-10 дев)
Інструменти	git-flow розширення	GitHub PRs + CI/CD
Частота злиття	Низька (функції збираються в develop)	Висока (щоденні PR в main)
Для чого	Electron, ігри, Chrome Extensions	Next.js на Vercel, VS Code open-source

Як Git відстежує гілки всередині

Git зберігає кожну гілку як легкий покажчик на коміт (SHA-1 хеш). Створення feature/login це просто запис невеликого файлу в .git/refs/heads/. Код не копіюється. При злитті Git знаходить спільного предка через git merge-base і накладає різницю або як fast-forward, або як merge commit. Git Flow додає CLI-скрипти (git flow feature start), які автоматизують створення гілок від develop. GitHub Flow обходиться без них і використовує PR-рушій GitHub, що виконує three-way merge на сервері.

Коли я вперше провів hotfix через повний Git Flow, автоматичний зворотний злив у develop врятував виправлення, яке інакше загубилось би в наступному релізному циклі. Але більшість вебкоманд, з якими я працював відтоді, використовують GitHub Flow і вирішують той самий граничний випадок через feature flags.

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

Злиття feature напряму в main у Git Flow

bash

git checkout feature/add-api   # гілка від develop
git checkout main
git merge feature/add-api      # пропускає develop, ламає інтеграцію

develop існує, щоб ловити інтеграційні баги до того, як вони потраплять у main. Пропустити цей крок означає зламати всю модель. Виправлення: git flow feature finish add-api зіллє в develop автоматично.

Тримати feature-гілки занадто довго в GitHub Flow

bash

git checkout -b feature/epic   # створено три тижні тому
git merge main                 # вибух конфліктів злиття

GitHub Flow вимагає коротких гілок (1-3 дні). Якщо функція займає тижні, розбий її на менші PR або сховай незавершену роботу за feature flags. Виправлення: git rebase main щодня.

Пропустити --no-ff при зливанні hotfix і release у Git Flow

bash

git merge release/v1.0         # fast-forward стирає крок релізу з історії

Без --no-ff історія виглядає лінійною і ти втрачаєш audit trail. Виправлення: git merge --no-ff release/v1.0.

Не видаляти злиті гілки

Мертві гілки накопичуються швидко. Через рік репозиторій може мати тисячі застарілих refs. Виправлення: увімкни автовидалення в налаштуваннях GitHub PR і регулярно запускай git remote prune origin.

Де це зустрічається в реальних проектах

React: GitHub Flow. Функції гілкуються від main, PR з CI-перевірками.
VS Code: GitHub Flow. Щоденні деплої main в Insiders build.
Linux kernel: варіант Git Flow. mainline виконує роль develop, stable/* як release-гілки.
Electron: Git Flow для версійних релізів на кшталт v25.0.0.
Kubernetes: trunk-based development (гілки живуть менше дня).

Питання на співбесіді

Q: Як провести hotfix у Git Flow?
A: Гілкуйся від main командою git flow hotfix start fix-crash. Вноси виправлення. Запускай git flow hotfix finish fix-crash. Це автоматично зіллє в main (з тегом v1.2.1) і в develop, щоб виправлення не загубилось у наступному циклі.

Q: Чому не використовувати GitHub Flow завжди?
A: Немає проміжного буфера для великих релізів. Без develop поганий злив може зламати main до того, як CI це спіймає. Git Flow дає місце для ловлі інтеграційних багів до продакшену.

Q: Як версіонувати релізи в GitHub Flow?
A: Злий у main і одразу створи git tag (v1.2). CI/CD підхопить тег і задеплоїть той конкретний коміт. Семантичне версіонування залишається, просто без окремої release-гілки.

Q: Що таке GitLab Flow і чим він відрізняється?
A: GitLab Flow додає environment-гілки типу staging і production між feature-гілками та main. Git Flow натомість використовує release-гілки, прив'язані до номерів версій. Різні моделі мислення, схожа мета.

Q: (Senior) Як GitHub Flow масштабується в монорепозиторії з 50 сервісами без поломки деплоїв?
A: Path filters у CI (changed-files: ['services/auth/**']) запускають лише потрібні задачі. Canary deploys і feature flags дозволяють зливати незавершений код без впливу на користувачів. Кожен сервіс отримує власний тег версії.

Приклади

Базовий: створення та злиття feature-гілки (GitHub Flow)

bash

git checkout main
git pull origin main
git checkout -b feature/use-auth-hook

# src/hooks/useAuth.js
# export const useAuth = () => { ... перевіряє токен у localStorage ... }

git add src/hooks/useAuth.js
git commit -m "Add useAuth hook with token check"
git push origin feature/use-auth-hook
# відкрити PR, 2 ревʼювери схвалюють
# auto-merge в main, CI проходить тести
# Vercel підхоплює main і деплоїть
git branch -d feature/use-auth-hook

PR відкрито, розглянуто, злито і задеплоєно в той самий день. Main жодного разу не була в нестабільному стані.

Просунутий: hotfix у Git Flow зі зворотним зливом у develop

bash

# Краш у продакшені під час підготовки release/v1.2
git checkout main
git checkout -b hotfix/critical-crash   # гілка від main, не від develop

# виправити краш
git add . && git commit -m "Fix null pointer in auth handler"

git checkout main
git merge --no-ff hotfix/critical-crash
git tag -a v1.2.1 -m "Hotfix: null pointer in auth"

git checkout develop
git merge --no-ff hotfix/critical-crash   # backport, щоб виправлення потрапило в наступний реліз

git branch -d hotfix/critical-crash

main отримує тег v1.2.1 і деплоїться. develop також має виправлення, тому наступний запланований реліз не поверне цей баг.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Дочитали статтю?