Git Flow: повний гайд з процесу розробки

Що таке Git Flow і навіщо він потрібен

Git Flow — це модель розгалуження Git, яка визначає чіткий процес управління гілками для команд розробки. Створена Вінсентом Дрісеном у 2010 році, ця методологія стала стандартом для проєктів з регулярними релізами та командною розробкою.

Основні переваги Git Flow:

• Чітке розділення типів гілок за призначенням
• Контрольований процес релізів
• Можливість паралельної розробки різних функцій
• Стабільність головної гілки
• Простота інтеграції з CI/CD

Коли використовувати Git Flow:

• Команди від 3+ розробників
• Проєкти з регулярними релізами
• Потреба в стабільній production-гілці
• Складні функції, що розробляються паралельно

Архітектура гілок у Git Flow

main          ──●────●────●────●────   (production releases)
               /      \    \    \
develop   ────●────────●────●────●───   (integration branch)
             /|        |\   |\   |\
feature/    ● |        | ●──● |  | ●   (new features)
           /  |        |      |  |  \
release/      |        ●──────●  |   
             |        /          |   
hotfix/      |       ●───────────●   (urgent fixes)
             |      /

Типи гілок та їх призначення

Тип гілки Призначення Створюється з Зливається в Час життя main Production код — - Постійна develop Інтеграція функцій main — Постійна feature/* Нові функції develop develop Тимчасова release/* Підготовка релізу develop main + develop Тимчасова hotfix/* Критичні виправлення main main + develop Тимчасова

Початкове налаштування Git Flow

Установка git-flow

# macOS
brew install git-flow

# Ubuntu/Debian
sudo apt-get install git-flow

# Windows (через Git Bash)
wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

Ініціалізація в проєкті

git flow init

При ініціалізації Git Flow запитає налаштування:

Branch name for production releases: [main] 
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

Гілка розробки та головна гілка

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

Створення develop гілки

Перший крок робочого процесу полягає у створенні гілки develop від стандартної гілки main:

git branch develop
git push -u origin develop

З git-flow розширенням

git flow init

Після ініціалізації:

$ git branch
* develop
  main

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

Функціональні гілки (feature)

З гілки develop створюються гілки feature. Коли робота над гілкою feature завершується, вона зливається в гілку develop.

Життєвий цикл feature гілки

graph LR
    A[develop] --> B[feature/user-auth]
    B --> C[Розробка функції]
    C --> D[Тестування]
    D --> E[Code Review]
    E --> F[Merge в develop]
    F --> G[Видалення feature гілки]

Команди для роботи з feature

Створення функціональної (feature) гілки

git flow feature start feature_branch

Робота над функцією

# Додавання змін
git add .
git commit -m "feat: implement user authentication"

# Періодичне оновлення з develop
git flow feature rebase feature_branch

Закінчення роботи з функціональною (feature) гілкою

git flow feature finish feature_branch

Публікація (feature)

git flow feature publish feature_branch

Отримання опублікованої (feature)

git flow feature pull origin MYFEATURE

Відстежувати (feature) в репозиторії origin

git flow feature track MYFEATURE

Практичний приклад

# Початок роботи над новою функцією
git flow feature start user-profile

# Розробка...
echo "User profile component" > user-profile.js
git add user-profile.js
git commit -m "feat: add user profile component"

echo "User profile styles" > user-profile.css
git add user-profile.css
git commit -m "style: add user profile styling"

# Завершення роботи (автоматично зливається в develop)
git flow feature finish user-profile

Гілки випуску (release)

З гілки develop створюється гілка release. Коли робота над гілкою release завершується, вона зливається з гілками develop і main.

Правила роботи з release гілками

1. Нові функції додати більше не можна — допускається лише виправлення багів, створення документації та вирішення інших завдань, пов’язаних із релізом
2. Коли підготовка до постачання завершується, гілка release зливається з main і їй присвоюється номер версії
3. Бажано одразу публікувати гілку релізу після створення, щоб дозволити іншим розробникам виконувати коміти в гілку релізу

Команди для роботи з release

Створення випуску (release) гілки

git flow release start '0.1.0'

Робота над релізом

# Виправлення багів
git add .
git commit -m "fix: resolve login issue"

# Оновлення документації
git commit -m "docs: update changelog for v0.1.0"

# Оновлення версії
git commit -m "bump: version 0.1.0"

Закінчення роботи з випуском (release) гілкою

git flow release finish '0.1.0'

Публікація випуску (release)

git flow release publish '0.1.0'

Відстежувати віддалений випуску (release)

git flow release track '0.1.0'

❗️ Не забудьте відправити зміни в тегах

git push --tags

Checklist для release

• [ ] Всі функції з develop інтегровані
• [ ] Пройдені всі тести
• [ ] Оновлена документація
• [ ] Оновлений CHANGELOG.md
• [ ] Версія оновлена в package.json
• [ ] Проведене QA тестування

Гілки виправлення (hotfix)

Якщо в гілці main виявляється критична проблема, з main створюється гілка hotfix. Коли робота над гілкою hotfix завершується, вона зливається з гілками develop і main.

Коли використовувати hotfix

• Критичні баги в production
• Проблеми безпеки
• Невідкладні виправлення
• Помилки, що впливають на роботу користувачів

Команди для роботи з hotfix

Створення виправлення (hotfix) гілки

git flow hotfix start hotfix_branch

Приклад роботи з hotfix

# Створення hotfix для критичної помилки
git flow hotfix start security-patch

# Виправлення проблеми
git add .
git commit -m "fix: resolve security vulnerability"

# Завершення hotfix (зливається в main і develop)
git flow hotfix finish security-patch

# Відправлення тегів
git push --tags

Закінчення роботи з виправленням (hotfix) гілкою

git flow hotfix finish hotfix_branch

Альтернативи і порівняння

GitHub Flow vs Git Flow

GitHub Flow vs Git Flow

Аспект Git Flow GitHub Flow Складність Висока Низька Кількість гілок 5 типів 2 типи Релізний цикл Заплановані релізи Continuous deployment Команда Великі команди Малі/середні команди

Коли НЕ використовувати Git Flow

• Continuous deployment
• Малі команди (1-2 розробники)
• Проєкти без регулярних релізів
• Проста структура проєкту

Практичні поради та найкращі практики

Конвенції іменування гілок

# Feature гілки
feature/user-authentication
feature/payment-integration
feature/admin-dashboard

# Release гілки  
release/1.2.0
release/2.0.0-beta

# Hotfix гілки
hotfix/critical-security-fix
hotfix/payment-bug-fix

Автоматизація з Git Hooks

# pre-commit hook для перевірки стилю коду
#!/bin/sh
npm run lint
npm run test

Інтеграція з CI/CD

# .github/workflows/gitflow.yml
name: Git Flow CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [develop]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run tests
        run: npm test

Командні угоди

1. Завжди створювати PR/MR для feature гілок
2. Code review обов’язковий перед злиттям
3. Тестування в release гілці перед production
4. Документувати зміни в CHANGELOG.md
5. Використовувати semantic versioning для тегів

Поширені помилки та як їх уникнути

❌ Пряме комітування в main/develop

# Неправильно
git checkout main
git commit -m "fix: urgent fix"

# Правильно
git flow hotfix start urgent-fix
# зробити зміни
git flow hotfix finish urgent-fix

❌ Забування про оновлення develop з main після hotfix

# Після hotfix завжди перевіряйте
git checkout develop
git pull origin develop

❌ Занадто великі feature гілки

# Розбивайте великі функції на менші
feature/user-system -> feature/user-auth + feature/user-profile

Інструменти та розширення

GUI інструменти з підтримкою Git Flow

• GitKraken — візуальний Git клієнт
• SourceTree — безкоштовний Git GUI
• Git Tower — професійний Git клієнт

VS Code розширення

• GitLens — розширені можливості Git
• Git Graph — візуалізація гілок
• Git Flow Extension — інтеграція Git Flow

Команди для відлагодження

# Перегляд поточного стану Git Flow
git flow version

# Перегляд активних гілок
git branch -a

# Історія комітів з графіком
git log --oneline --graph --all

# Статус всіх гілок
git show-branch --all

Заключення

Git Flow — потужний інструмент для організації командної розробки, який забезпечує стабільність і контрольованість процесу розробки. Хоча він може здатися складним на початку, правильне використання Git Flow значно покращує якість коду та ефективність команди.

Ключові моменти для запам’ятовування:

• main — завжди стабільний production код
• develop — інтеграційна гілка для нових функцій
• feature — окремі функції розробляються ізольовано
• release — підготовка до випуску з фіксацією функцій
• hotfix — швидкі критичні виправлення

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

Корисні ресурси

Матеріал для цієї статті використовувався з кількох джерел:

1. Atlassian Git Flow Tutorial
2. Git Flow Cheatsheet
3. A successful Git branching model
4. Git Flow vs GitHub Flow

Додаткові ресурси:

• Semantic Versioning
• Conventional Commits
• Git Best Practices
• Software Versioning: A Comprehensive Guide Версіювання ПЗ: Комплексний Посібник

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті