Стратегии ветвления Git: Git Flow, GitHub Flow, trunk-based

Короткий ответ

Стратегия ветвления — это договорённость команды о том, какие ветки существуют, откуда они создаются и как код попадает в релиз. Три самые распространённые:

• Git Flow — много долгоживущих веток, релизы версиями. Подходит, когда выпуски редкие и нужно поддерживать несколько версий.
• GitHub Flow — одна главная ветка и короткие feature-ветки через pull request. Подходит большинству веб-проектов.
• Trunk-based development — все часто вливают маленькие изменения прямо в основную ветку. Подходит командам с хорошими тестами, CI и feature flags.

Выбор определяется не модой, а частотой релизов, размером команды и зрелостью автоматизации.

Git Flow

Две постоянные ветки: main (то, что в продакшене) и develop (интеграция). Плюс вспомогательные: feature/*, release/*, hotfix/*.

main     ●──────────────●──────────●
          \            / \        /
release    \      ●──●   \      /
            \    /         hotfix
develop      ●──●──●──●──●──●
              \   /
feature        ●─●

Плюсы: понятный процесс релиза, удобно сопровождать несколько версий (мобильные приложения, коробочный софт, библиотеки).

Минусы: много слияний и конфликтов, изменения долго идут до продакшена, процесс тяжело совмещать с непрерывной доставкой.

GitHub Flow

Одна постоянная ветка main, которая всегда готова к деплою. Любая работа — короткая ветка, pull request, ревью, проверки CI, слияние, деплой.

main     ●───●───────●───●───────●
          \     /     \     /
feature    ●──●        ●──●

Плюсы: просто объяснить новичку, быстрый путь до продакшена, ревью через pull request встроено в процесс.

Минусы: если ветки живут неделями, возвращаются конфликты; нет отдельного места для подготовки релиза, поэтому нужен надёжный CI.

Trunk-based development

Все разработчики вливают изменения в основную ветку (trunk) часто — минимум раз в день. Ветки если и есть, то живут часы, а не дни.

main     ●─●─●─●─●─●─●─●─●─●
            \ /     \ /
             ●       ●      (ветки на несколько часов)

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

Минусы: требует дисциплины, хорошего покрытия тестами и быстрого CI. Без этого основная ветка будет часто ломаться.

Feature flags: как trunk-based работает с незаконченными задачами

Главный вопрос к trunk-based: как вливать в main фичу, которая ещё не готова? Ответ — feature flags (флаги функций).

Код новой функции попадает в основную ветку, но включается условием:

if (flags.isEnabled("new-checkout", user)) {
  renderNewCheckout();
} else {
  renderOldCheckout();
}

Что это даёт:

• Деплой отделён от релиза. Код уже на сервере, но пользователи его не видят.
• Постепенный запуск. Сначала включить для команды, потом для части пользователей, затем для всех.
• Быстрый откат. Выключить флаг проще и быстрее, чем откатывать деплой.

Флаги нужно удалять после полного запуска, иначе код зарастает ветвлениями, которые никто не помнит.

Сравнение

Как выбрать

1. Нужно поддерживать несколько версий одновременно? Git Flow или его упрощённый вариант с release-ветками.
2. Веб-продукт, деплой несколько раз в неделю, команда небольшая? GitHub Flow.
3. Сильный CI, быстрые тесты, готовность внедрить feature flags? Trunk-based.
4. Сомневаетесь? Начните с GitHub Flow и держите ветки короткими — это естественный путь к trunk-based.

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

• Выбрать Git Flow «потому что так принято» для сайта, который деплоится ежедневно.
• Держать feature-ветку месяц и потом неделю разрешать конфликты.
• Перейти на trunk-based без автотестов.
• Оставлять в коде десятки устаревших feature flags.