Стратегии ветвления

Стратегия ветвления -- это набор правил, которым команда следует при создании, именовании и слиянии веток. Правильная стратегия зависит от размера команды, частоты релизов и модели развёртывания.

Git Flow

Git Flow использует долгоживущие ветки со строгой структурой:

main ─────────────────────── (производственные релизы)
  \                       /
   develop ──────────────── (ветка интеграции)
     \         \        /
      feature-a  feature-b

Ветки в Git Flow

• main -- всегда отражает продакшен. Получает слияния только из веток release или hotfix.
• develop -- ветка интеграции. Функциональность сначала сливается сюда.
• feature/ -- по одной на функциональность, ответвляются от develop, сливаются обратно в develop.
• release/ -- ответвляются от develop при подготовке релиза. Исправления ошибок вносятся сюда, затем сливаются и в main, и в develop.
• hotfix/ -- ответвляются от main для срочных исправлений в продакшене. Сливаются и в main, и в develop.

Преимущества

• Чёткое разделение между разработкой и продакшеном
• Хорошо подходит для запланированных релизов (например, каждые 2 недели)
• Можно поддерживать несколько версий одновременно

Недостатки

• Сложно -- много типов веток и правил слияния
• Долгоживущие ветки часто приводят к болезненным конфликтам слияния
• Медленно для команд, которые развёртывают непрерывно

GitHub Flow

GitHub Flow значительно проще -- есть только одна долгоживущая ветка: main.

main ──A──B──────E──F──────── (всегда готова к развёртыванию)
          \     /   \     /
           C──D      G──H
           (PR)       (PR)

Правила

1. main всегда готова к развёртыванию
2. Создавайте ветку от main для каждого изменения
3. Откройте пулл-реквест, когда готовы к ревью
4. После ревью слейте в main
5. Развёртывайте из main

Преимущества

• Просто -- всего одно правило
• Быстрая обратная связь через пулл-реквесты
• Хорошо работает с непрерывным развёртыванием

Недостатки

• Нет разделения между "разработкой" и "продакшеном"
• Сложнее поддерживать несколько версий релизов
• Требует хорошего CI/CD для обнаружения проблем до слияния

Trunk-Based Development (разработка на основе основной ветки)

Trunk-based development доводит простоту до предела -- все коммитят в main ("ствол") напрямую или через очень короткоживущие ветки (часы, а не дни).

main ──A──B──C──D──E──F──G──── (все коммитят сюда)
          \  /      \  /
           ──        ──
        (короткие) (короткие)

Правила

1. Все работают в main (или сливают в течение нескольких часов)
2. Ветки живут максимум день
3. Используйте фиче-флаги для скрытия незавершённой работы
4. CI запускается на каждый коммит

Преимущества

• Минимум конфликтов слияния (ветки короткоживущие)
• Самый быстрый цикл интеграции
• Поощряет маленькие, инкрементальные изменения

Недостатки

• Требует зрелого CI/CD и тестирования
• Фиче-флаги добавляют сложность в кодовую базу
• Не подходит, если нет возможности развёртывать часто

Сравнение

Какую выбрать?

• Только начинаете? Используйте GitHub Flow. Это просто и эффективно.
• Выпускаете версионное ПО (мобильные приложения, библиотеки)? Git Flow даст вам структуру.
• Развёртываете несколько раз в день? Trunk-based development минимизирует трение.

Универсально правильного ответа не существует. Лучшая стратегия -- та, которой ваша команда может следовать последовательно.

Ключевая идея

Стратегии ветвления -- это про людей и процессы, а не про возможности Git. Git одинаково хорошо поддерживает все эти подходы. Выберите тот, который соответствует тому, как ваша команда на самом деле выпускает код.