← Back to notes

Git стратегии
ветвления

2025-10-26

#cli

Стратегия ветвления нужна не Git сам по себе, а release-процессу: она задаёт, где живёт готовый к выпуску код, как коротко держать integration gap и какие проверки блокируют merge.

Feature Branch Workflow

Каждая задача делается в отдельной ветке от main или develop, затем проходит Pull Request / Merge Request и CI. Ветка должна быть короткоживущей; если она живёт неделями, команда получает delayed integration и больше конфликтов.

Подходит для команд, где нужен review перед merge, но нет сложного release train.

Git Flow

Модель Vincent Driessen с долгоживущими main и develop, плюс feature/*, release/*, hotfix/*. Сам автор позже уточнял, что Git Flow не является универсальной рекомендацией для continuous delivery/web-app сценариев.

Структура:

  main
  develop
  ├── feature/*
  ├── release/*
  └── hotfix/*

Рабочий процесс:

  1. Разработка идёт в develop
  2. Новые функции --- в feature/имя
  3. Перед релизом --- ветка release/x.x.x
  4. После релиза --- merge в main и develop
  5. Срочные багфиксы --- из main в hotfix/, затем обратно в обе ветки

Плюсы: явная подготовка релиза, отдельный hotfix-путь, удобно для версионируемых продуктов с релизными окнами.

Минусы: много merge-точек, долгоживущий develop, задержка интеграции. Для частых production deploys часто проще trunk-based.

Trunk-Based Development

Все изменения быстро попадают в main/trunk; feature-ветки либо не используются, либо живут часы/1-2 дня. Незавершённое поведение прячется за feature flags или branch by abstraction.

Плюсы: настоящая Continuous Integration, меньше merge debt, проще continuous delivery.

Минусы: нужен быстрый и надёжный CI, культура маленьких изменений, feature flags и оперативный rollback.

Выбор стратегии

  • Стартап, быстрый цикл релизов - Trunk-Based
  • Средний проект с обязательным review - Feature Branch Workflow
  • Версионируемый продукт с release train - Git Flow

Best Practices

  • Делайте маленькие feature-ветки, живущие не более 1--2 дней
  • Автоматизируйте merge и проверки через CI/CD
  • Не используйте git push --force в общих ветках
  • Включайте code review и quality gates
  • Документируйте процесс ветвления в CONTRIBUTING.md

Ссылки

Git стратегии ветвления | Aleksandr Suprun