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

GitMiddle~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

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