Если у тебя в команде больше двух разработчиков, рано или поздно вы упрётесь в бардак из-за веток в Git. То фичи смешались с багфиксами, то релизы неотслеживаемые, то кто-то случайно замержил не туда… Короче, хаос. Вот тут и приходит на помощь Git Flow — стратегия ветвления, которая реально помогает держать проект под контролем. Рассказываю, как внедрить, не сломать и не возненавидеть Git.

Возможности Git Flow

• Четкая структура веток: master, develop, feature, release, hotfix.
• Ясные правила — кто, куда и когда коммитит.
• Ускоряет релизы и багфиксы — меньше конфликтов и недопониманий.
• Просто откатить фичу или багфикс, если что-то пошло не так.
• Подходит для распределённых команд и open-source.

Что требуется

• ОС: Любая — Linux, macOS, Windows (WSL, Git Bash, PowerShell — всё работает).
• Железо: Если у тебя тянет браузер и IDE, то и Git потянет.
• Git: Версия 2.0+ (проверь git --version).
• git-flow: Утилита для работы с этим процессом (не обязательно, но удобно).

Установка — пошаговая инструкция

1. Проверь, что Git установлен:
   git --version
   Если нет — скачай тут.
2. Устанавливаем git-flow:
   • macOS (через brew):
     brew install git-flow
   • Linux (Debian/Ubuntu):
     sudo apt-get install git-flow
   • Windows:
     Инструкция тут (или ставь через Chocolatey: choco install gitflow).
3. Инициализация Git Flow в проекте:
   Перейди в папку с репозиторием:
   cd /path/to/your/project
   Запусти инициализацию:
   git flow init
   Тебя спросят про имена веток — можно оставить дефолтные (рекомендую):
   • Production branch name: master
   • Development branch name: develop
   • Feature branches: feature/
   • Release branches: release/
   • Hotfix branches: hotfix/
   • Support branches: (можно не трогать)
4. Проверь структуру веток:
   git branch
   Должны быть master и develop.

Использование: команды и варианты

Вот прям полный список команд, которые реально нужны:

• Создать новую фичу:
  git flow feature start название_фичи
• Закончить фичу (вмержить в develop):
  git flow feature finish название_фичи
• Начать релизную ветку:
  git flow release start номер_релиза
• Закончить релиз (мерж в master + develop, тег):
  git flow release finish номер_релиза
• Начать хотфикс (если в master баг):
  git flow hotfix start номер_хотфикса
• Закончить хотфикс (мерж в master + develop, тег):
  git flow hotfix finish номер_хотфикса
• Посмотреть все активные ветки:
  git flow feature list
git flow release list
git flow hotfix list

Можно делать всё это руками через обычный git checkout, git merge и т.д., но git-flow автоматизирует рутину, не даст забыть про теги и правильные мержи.

Официальный репозиторий: https://github.com/nvie/gitflow

Ошибки и как делать не надо

• Не коммить фичи напрямую в develop/master. Только через ветки!
• Не держи фичу слишком долго. Чем дольше ветка живёт — тем больнее мержить.
• Не забывай про pull перед стартом фичи/релиза. Иначе потом конфликты.
• Не делай хотфиксы из develop. Только из master, иначе баги уйдут не туда.
• Не плодить релизные ветки. Одна релизная ветка — один релиз.

Пример реального использования

В команде из 5 человек (backend + frontend) внедрили git-flow на проекте с микросервисами. Раньше каждый делал фичи как хотел, иногда баги ловили только в проде, релизы откатывали через force-push. После перехода на git-flow:

• Каждая фича — отдельная ветка, QA тестит на деве.
• Релизная ветка — только для финальных багфиксов и подготовки к деплою.
• Хотфиксы — мгновенно попадают в мастер и девелоп, не ломая новые фичи.

Сэкономили кучу времени на разруливание конфликтов и объяснения “кто куда чего замержил”. Даже джуны быстро врубились, что куда коммитить.

Заключение

Git Flow — не серебряная пуля, но для команд с несколькими разработчиками и регулярными релизами это реально must-have. Структура простая, команды запоминаются быстро, а бардак в репозитории уменьшается в разы. Если хочешь копнуть глубже — вот оригинальный пост от автора и репозиторий git-flow. Не бойся пробовать — через неделю уже не захочешь работать без этой схемы!