Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «Стратегії гілкування Git (Git Flow, GitHub Flow)?». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (UA)

**Стратегії гілкування 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` також має виправлення, тому наступний запланований реліз не поверне цей баг.

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати1181 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.