Как у вас был организован git flow?

Git Flow — это модель ветвления, предложенная Винсентом Дриссеном, которая определяет строгие правила создания и слияния веток в Git. Она предназначена для проектов с чётким циклом релизов и помогает управлять параллельной разработкой, стабилизацией и поддержкой.

Ключевые ветки

• main (master): содержит только стабильный, готовый к продакшену код. Каждый коммит здесь — это новый релиз.
• develop: основная ветка для интеграции новых функций. Сюда сливаются завершённые feature-ветки.
• feature/*: создаются от develop для разработки новой функциональности. После завершения сливаются обратно в develop.
• release/*: создаются от develop, когда накоплено достаточно изменений для нового релиза. Здесь идёт финальное тестирование и исправление багов. После готовности сливается и в main (с тегом версии), и в develop (чтобы перенести исправления).
• hotfix/*: создаются от main для срочного исправления в продакшене. После исправления сливаются и в main (новый патч-релиз), и в develop.

Пример рабочего процесса

# Создание feature-ветки для новой задачи
git checkout develop
git checkout -b feature/user-authentication

# Работа над задачей, коммиты...
git add .
git commit -m "Add login form"

# Завершение feature: слияние в develop
git checkout develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication

# Когда готов релиз, создаём release-ветку
git checkout -b release/v1.2.0 develop
# Тестирование, исправление багов прямо в этой ветке...

# Завершение релиза: слияние в main и develop
git checkout main
git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"
git checkout develop
git merge --no-ff release/v1.2.0
git branch -d release/v1.2.0

# Срочный hotfix для продакшена
git checkout main
git checkout -b hotfix/critical-security-patch
# Исправление...
git commit -m "Fix security vulnerability"
git checkout main
git merge --no-ff hotfix/critical-security-patch
git tag -a v1.2.1 -m "Hotfix release 1.2.1"
git checkout develop
git merge --no-ff hotfix/critical-security-patch
git branch -d hotfix/critical-security-patch

Где применяется

Git Flow хорошо подходит для проектов с долгосрочными релизами (например, десктопные приложения, корпоративное ПО), где есть чёткие версии и необходимость поддерживать несколько версий одновременно. Для сервисов с непрерывным развёртыванием (CI/CD) часто используют более простые модели, такие как GitHub Flow (одна основная ветка, feature-ветки сливаются через pull request) или GitLab Flow (с окружениями).

Вывод: Git Flow стоит применять в командах, где важна строгая дисциплина релизов, изоляция стадий разработки и поддержка нескольких версий продукта. Для небольших команд или сервисов с частыми деплоями он может быть избыточным.