Gitflow

Модель ветвления для организации командной разработки: main, develop, feature, release, hotfix

Зачем нужно

  • Стандартизировать работу с ветками в команде
  • Разделить разработку, релизы и срочные исправления
  • Предсказуемый процесс выпуска версий

Где используется

  • Проекты с регулярными релизами
  • Командная разработка (3+ человек)
  • Проекты с поддержкой нескольких версий

Предпосылки

Структура Gitflow

main        ●──────────────────●──────────────●  (только релизы)
             \                / \            /
release       \    ●──●──●──●   \   ●──●──●
               \  /              \ /
develop    ●──●──●──●──●──●──●──●──●──●──●──●  (основная разработка)
              \      /  \      /
feature        ●──●──●   ●──●──●
                              \
hotfix                         ●──●  (срочное исправление из main)

Ветки

main (production)

  • Содержит только стабильные релизы
  • Каждый коммит — это release с тегом версии
  • Напрямую коммитить нельзя

develop

  • Основная ветка разработки
  • Содержит последние завершённые фичи
  • Из неё создаются feature и release ветки

feature/*

# Создание
git switch develop
git switch -c feature/user-profile

# Работа
git commit -m "feat: добавить страницу профиля"
git commit -m "feat: добавить загрузку аватара"

# Завершение — merge в develop
git switch develop
git merge --no-ff feature/user-profile
git branch -d feature/user-profile

release/*

# Подготовка к релизу
git switch develop
git switch -c release/1.2.0

# Только фиксы и подготовка
git commit -m "chore: обновить версию до 1.2.0"
git commit -m "fix: исправить баг в навигации"

# Merge в main И develop
git switch main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"

git switch develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

hotfix/*

# Срочное исправление в production
git switch main
git switch -c hotfix/security-fix

git commit -m "fix: закрыть XSS-уязвимость"

# Merge в main И develop
git switch main
git merge --no-ff hotfix/security-fix
git tag -a v1.2.1 -m "Hotfix 1.2.1"

git switch develop
git merge --no-ff hotfix/security-fix
git branch -d hotfix/security-fix

Версионирование (SemVer)

v1.2.3
│ │ │
│ │ └── PATCH — исправление бага (hotfix)
│ └──── MINOR — новая функциональность (feature)
└────── MAJOR — несовместимые изменения (breaking changes)
Что произошло Пример
Исправили баг 1.2.3 → 1.2.4
Добавили фичу 1.2.3 → 1.3.0
Сломали обратную совместимость 1.2.3 → 2.0.0

Альтернатива: Trunk-Based Development

Более простая модель, популярная в командах с CI/CD:

main:   ●──●──●──●──●──●──●──●  (все коммитят сюда)
           \  /    \  /
feature:    ●       ●     (живут максимум 1-2 дня)

Принципы

  • Одна ветка — main
  • Feature-ветки живут максимум 1-2 дня
  • Маленькие, частые PR
  • Feature flags вместо долгих веток
  • CI/CD на каждый коммит

Сравнение

Gitflow Trunk-Based
Сложность Высокая (5 типов веток) Низкая (main + short features)
Время жизни ветки Дни — недели Часы — 1-2 дня
Подходит для Запланированные релизы Непрерывный деплой
Размер команды Большие команды Любой размер
CI/CD Не обязательно Обязательно
Feature flags Не нужны Часто нужны

Что выбрать?

  • Gitflow: мобильные приложения, ПО с версиями, команды без CI/CD
  • Trunk-Based: веб-приложения, SaaS, команды с CI/CD, стартапы

GitHub Flow (упрощённый)

Компромисс между Gitflow и Trunk-Based:

main:    ●──●──●──●──●──●
            \  /  \    /
feature:     ●     ●──●
  1. main всегда деплоится
  2. Создать ветку от main
  3. Коммитить, создать PR
  4. Code review
  5. Merge в main
  6. Deploy

Частые ошибки

  • Gitflow для простых проектов — overeengineering для одиночного разработчика
  • Долгоживущие feature-ветки — накапливаются конфликты
  • Забывать merge hotfix в develop — фикс потеряется в следующем релизе
  • Не использовать --no-ff — теряется история что была отдельная ветка
  • Не ставить теги на релизы — непонятно какой коммит какому релизу соответствует

Практика

  1. Создайте репозиторий с ветками main и develop
  2. Создайте feature-ветку, поработайте и влейте в develop
  3. Создайте release-ветку, смержите в main и develop
  4. Поставьте тег v1.0.0 на main
  5. Создайте hotfix и смержите в main и develop
  6. Попробуйте GitHub Flow на отдельном проекте — сравните удобство

Связанные темы

Ресурсы