Что такое GitFlow?

GitFlow: Стандартизированный Workflow для управления версиями

GitFlow — это наиболее популярная модель ветвления (branching model) для Git-репозиториев, разработанная Vincent Driessen в 2010 году. Она предоставляет структурированный подход к параллельной разработке и управлению релизами.

Основные ветки

ГитFlow использует две постоянные ветки (которые всегда существуют):

1. main (или master)

• Содержит исключительно production-ready код
• Каждый коммит в main соответствует новому релизу
• Защищена от прямых коммитов — только merge из release и hotfix ветвей
• Обычно ассоциирована с версионированием: v1.0.0, v1.1.0 и т.д.

2. develop

• Интеграционная ветка для разработки
• Содержит latest development changes
• Служит базой для всех feature ветвей
• Здесь тестируется интеграция новых функций

Вспомогательные ветки

Это временные ветки, удаляемые после слияния:

Feature ветки (feature/*)

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

# После завершения разработки
git checkout develop
git pull origin develop
git merge --no-ff feature/user-authentication
git push origin develop
git branch -d feature/user-authentication

Назначение:

• Разработка новых функций изолированно
• Несколько разработчиков могут работать на разных features параллельно
• Базируется на develop, не touching production code

Release ветки (release/*)

# Создание release ветки для подготовки к выпуску
git checkout -b release/1.2.0 develop

# Финальные правки, bug fixes, версионирование
# Обновляем версию в package.json или других файлах
echo "1.2.0" > VERSION

# Слияние в main
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"

# Обратное слияние в develop
git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

Назначение:

• Подготовка к production release
• Финальное тестирование и minor bug fixes
• Не содержит новых features, только стабилизацию
• Позволяет команде работать над features в develop, пока release готовится

Hotfix ветки (hotfix/*)

# Срочное исправление критичного бага в production
git checkout -b hotfix/1.2.1 main

# Быстрое исправление
# После тестирования
git checkout main
git merge --no-ff hotfix/1.2.1
git tag -a v1.2.1 -m "Hotfix version 1.2.1"

# Обновление develop
git checkout develop
git merge --no-ff hotfix/1.2.1
git branch -d hotfix/1.2.1

Назначение:

• Экстренные исправления критичных ошибок в production
• Базируется на main, не на develop
• После слияния в main одновременно обновляет develop

Типичный Flow цикла разработки

1. Инициализация проекта:

   • Создаёшь develop из main
   • main защищена от прямых коммитов

2. Разработка функции:

   • Создаёшь feature/new-feature из develop
   • Работаешь изолированно
   • Push changes и создаёшь Pull Request
   • После code review merge в develop

3. Подготовка релиза:

   • Когда готово к выпуску, создаёшь release/X.Y.Z из develop
   • Проводишь финальное тестирование
   • Фиксишь только critical bugs
   • Merge в main с tag версии
   • Обратное слияние в develop

4. Экстренное исправление:

   • Если обнаружен bug в production
   • Создаёшь hotfix из main
   • Быстро фиксишь и merge обратно

Преимущества GitFlow

✅ Организованность — четкая структура ветвления ✅ Параллельная разработка — несколько feature одновременно ✅ Управление релизами — контролируемый процесс выпуска ✅ Стабильность production — main защищена ✅ Hotfix процесс — быстрое реагирование на emergency ✅ Ясный history — легко отследить, что в какой версии

Недостатки

❌ Сложность — много ветвей и правил ❌ Медленнее — чем GitHub Flow для continuous deployment ❌ Overkill — для малых команд может быть излишним

Альтернативные модели

• GitHub Flow — simpler, для continuous deployment
• Trunk-Based Development — все разработчики в одной ветке
• GitLab Flow — промежуточный вариант между GitHub и GitFlow

Для Data Engineering команд GitFlow особенно ценен при работе с несколькими версиями pipeline и management критичных данных в production.