Modern QA2026Стратегии ветвления
Join

Course › 17 Git & Version Control

Foundations · Chapter 17

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

Updated Jul 2026

Почему стратегия ветвления важна для QA

Стратегия ветвления, используемая вашей командой, определяет, как вы управляете тестовыми ветками, когда запускаете какие тесты и как релизы соотносятся с результатами тестирования. Понимание стратегии не является опциональным — оно напрямую формирует ваш план выполнения тестов.

Три основные стратегии

Аспект GitFlow GitHub Flow Trunk-Based Development
Основные ветки main + develop только main только main
Фича-ветки Ответвляются от develop, сливаются обратно в develop Ответвляются от main, сливаются через PR Короткоживущие ветки (< 1 дня), сливаются в main
Процесс релиза Ветка release/* для стабилизации Развёртывание из main после слияния Непрерывное развёртывание из main
Хотфиксы Ветка hotfix/* от main Ответвление от main, слияние через PR Исправление непосредственно в main
Сложность Высокая — несколько долгоживущих веток Низкая — одна основная ветка Низкая — но требует зрелого CI/CD
Лучше всего для Запланированных релизов, нескольких версий в продакшене SaaS с непрерывным развёртыванием Команд с сильной автоматизацией тестирования и feature flags

GitFlow подробно

GitFlow использует две долгоживущие ветки (main и develop) плюс короткоживущие ветки для фич, релизов и хотфиксов.

main ──────────────●───────────────────●──────── (продакшен-релизы)
                   ↑                   ↑
release/2.3 ──────●   release/2.4 ────●
                   ↑                   ↑
develop ───●──●──●─┘──●──●──●──●──●───┘──●──── (ветка интеграции)
           ↑  ↑  ↑    ↑  ↑  ↑  ↑  ↑      ↑
           фича-ветки (короткоживущие)

Последствия GitFlow для QA

  • Тестируйте на develop: каждая фича, слитая в develop, должна запускать регрессионные тесты
  • Тестируйте повторно на release/*: ветка релиза предназначена для стабилизации. Сюда попадают только исправления багов, и каждое исправление требует тестирования
  • Двойная нагрузка тестирования: вы можете тестировать фичу на develop, а затем тестировать ту же фичу снова на ветке релиза
  • Тестирование хотфиксов: хотфиксы ответвляются от main, тестируются, сливаются в main и develop
  • Сопоставление окружений: develop соответствует dev/integration-окружению, release/* — staging, main — продакшену

Когда выступать за GitFlow:

  • Ваш продукт имеет запланированные релизы (квартальные, ежемесячные)
  • Одновременно поддерживаются несколько версий (v2.3 и v2.4 обе в продакшене)
  • Регуляторные требования предписывают фазу стабилизации перед релизом

GitHub Flow подробно

GitHub Flow использует единственную ветку main. Вся работа ведётся в фича-ветках, которые сливаются через pull request.

main ──────●──●──●──●──●──●──●──●──●──── (всегда готов к развёртыванию)
           ↑  ↑  ↑  ↑  ↑  ↑  ↑  ↑  ↑
           PR из фича-веток

Последствия GitHub Flow для QA

  • Тестируйте на PR: каждый pull request запускает полный набор тестов. Это ваша основная контрольная точка качества.
  • Main всегда готов к развёртыванию: если тесты прошли на PR и PR слит, main должен быть безопасен для развёртывания в любое время
  • Нет фазы стабилизации: ветки релиза нет. Если что-то сломано в main, исправляйте это другим PR.
  • Простое сопоставление окружений: фича-ветки развёртываются в preview-окружения, main развёртывается в продакшен

Когда выступать за GitHub Flow:

  • Ваша команда практикует непрерывное развёртывание (развёртывание несколько раз в день)
  • В продакшене одна версия
  • Ваш CI-пайплайн достаточно быстр и надёжен, чтобы эффективно блокировать PR

Trunk-Based Development подробно

Trunk-based development доводит GitHub Flow до крайности. Фича-ветки живут менее одного дня. Разработчики коммитят в main часто, зачастую несколько раз в день.

main ──●●●●●●●●●●●●●●●●●●●●●● (непрерывный поток мелких коммитов)
       ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
       Очень короткоживущие ветки (часы, не дни)

Последствия Trunk-Based Development для QA

  • Каждый коммит должен проходить все тесты: фазы стабилизации нет. Пайплайн должен быть быстрым и надёжным.
  • Feature flags заменяют фича-ветки: незавершённые функции развёртываются за флагами, а не в отдельных ветках
  • Тестирование резко смещается влево: QA участвует в анализе требований и пишет тесты до начала разработки, потому что позже догонять будет некогда
  • Нестабильные тесты — экзистенциальная угроза: нестабильный тест, блокирующий main, блокирует всю команду. Исправляйте нестабильные тесты немедленно.

Когда trunk-based development работает:

  • Команда обладает высокой зрелостью автоматизации тестирования (>90% тестов автоматизировано)
  • CI-пайплайн завершается менее чем за 10 минут
  • Feature flags доступны и хорошо управляются
  • Команда обладает строгой дисциплиной code review

Адаптация тестового плана к стратегии

Стратегия Когда запускать unit-тесты Когда запускать интеграционные тесты Когда запускать E2E-тесты Когда запускать полную регрессию
GitFlow При каждом push При PR в develop При PR в develop На ветке релиза, перед слиянием в main
GitHub Flow При каждом push При каждом PR При каждом PR При слиянии в main (перед развёртыванием)
Trunk-Based При каждом push При каждом push или PR При слиянии в main Непрерывно (при каждом развёртывании)

Переход между стратегиями

Команды часто начинают с GitFlow и мигрируют к GitHub Flow или trunk-based development по мере роста зрелости автоматизации. Если ваша команда рассматривает переход, вот что QA нужно подготовить:

Переход с GitFlow на GitHub Flow

  1. Ускорьте пайплайн: GitHub Flow полагается на проверки PR как основную контрольную точку. Если ваш пайплайн занимает 40 минут, PR будут мучительными.
  2. Устраните фазу тестирования ветки релиза: всё тестирование должно происходить на PR. Все тесты, которые запускались только на ветке релиза, должны переехать в пайплайн PR.
  3. Улучшите надёжность тестов: в GitFlow нестабильный тест на ветке релиза мог быть терпимым. В GitHub Flow нестабильный тест блокирует каждый PR.

Переход с GitHub Flow на Trunk-Based

  1. Внедрите feature flags: вам нужен способ безопасно развёртывать незавершённые функции.
  2. Сократите время пайплайна до менее 10 минут: разработчики не могут ждать 20 минут при каждом небольшом коммите.
  3. Достигните практически нулевого уровня нестабильных тестов: каждый сбой теста в main блокирует команду.
  4. Сместите QA раньше: QA должно участвовать в проектировании и формулировании требований, а не ждать кода.

Практическое упражнение

  1. Определите, какую стратегию ветвления использует ваша текущая команда.
  2. Отобразите, когда каждый тип тестов запускается в вашем рабочем процессе. Есть ли пробелы?
  3. Если ваша команда использует GitFlow, выявите тесты, которые запускаются дважды (на develop и на release). Можно ли устранить дублирование?
  4. Если ваша команда использует GitHub Flow, измерьте время пайплайна PR. Укладывается ли оно в 15 минут?
  5. Предложите одно улучшение плана выполнения тестов вашей команды на основе стратегии ветвления.