PrepBro
← Назад к вопросам

Как работал с GitFlow

1.0 Junior🔥 131 комментариев
#Soft Skills и карьера

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI22 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

# Git Flow: Опыт работы и лучшие практики

Git Flow — это модель ветвления, которая обеспечивает структурированный подход к разработке, поддержке версий и релизам. Я использовал эту модель в нескольких проектах, и могу поделиться опытом.

1. Основная структура Git Flow

master (main) — production ветка, release/* — ветки для релизов, develop — интеграционная ветка, feature/* — новые возможности, bugfix/* — исправления в develop, hotfix/* — критичные исправления в master

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

2.1 Master branch (Production)

Master содержит только стабильный production код. Каждый commit в master = новая версия. Каждый релиз помечается тегом (v1.0.0, v0.9.0, v0.8.5).

2.2 Develop branch (Integration)

Develop — это основная ветка для разработки. Содержит код для следующего релиза. После каждого релиза обновляется из master.

3. Ветки функциональности (Feature Branches)

3.1 Создание feature ветки

Новая задача: добавить аутентификацию через OAuth2

git checkout develop
git pull origin develop
git checkout -b feature/oauth2-authentication

Или с использованием git-flow:

git flow feature start oauth2-authentication

3.2 Разработка feature

Работаем в ветке feature, делаем несколько коммитов для разных частей функциональности, тестов и документации.

3.3 Завершение feature (Pull Request)

Отправляем на remote и создаём Pull Request:

  • Title: Feature: Add OAuth2 authentication
  • Base branch: develop
  • Compare branch: feature/oauth2-authentication

3.4 Code Review и merge

После одобрения PR мержим в develop с флагом --no-ff (сохраняет историю). Удаляем feature ветку.

4. Release branches

4.1 Подготовка к релизу

Когда develop готов к релизу v1.5.0, создаём release ветку, обновляем версию в коде (pom.xml, build.gradle).

4.2 Тестирование и багфиксы в release

Нашли баг — фиксим в release ветке, обновляем версию (patch: 1.5.0 → 1.5.1).

4.3 Завершение release

Мержим в master, создаём tag для версии, мержим обратно в develop, обновляем версию в develop на следующую (1.6.0-SNAPSHOT), отправляем всё.

5. Hotfix branches (критичные исправления)

5.1 Критичный баг в production

Production (main) версия 1.5.1 упала с критичной ошибкой. Нужно срочно исправить.

git checkout main
git pull origin main
git checkout -b hotfix/1.5.2 main

5.2 Исправление hotfix

Быстро фиксим критичный баг, обновляем версию (patch).

5.3 Завершение hotfix

Мержим в main, создаём tag, мержим в develop, отправляем всё.

6. Правила коммитов в Git Flow

Feature коммиты: Feature: Add OAuth2 authentication Bugfix коммиты: Bugfix: Fix null pointer exception in UserService Hotfix коммиты: Hotfix: Fix critical SQL injection vulnerability Release коммиты: Release: Version 1.5.0

7. Реальный пример: полный цикл разработки

Неделя 1: Разработка

Фrontend разработчик создает feature ветку, работает, создает PR, получает одобрение, мержит в develop. Backend разработчик делает то же самое для api-v2-endpoints.

Неделя 2: Подготовка к релизу

Product Manager говорит выпустить версию 2.0.0. Создаём release ветку. QA находит баги. Developer фиксит в release ветке. После одобрения finish release.

Версии:

  • main: 2.0.0 (tagged v2.0.0)
  • develop: 2.1.0-SNAPSHOT

День развёртывания в production

CI/CD pipeline читает tag v2.0.0, собирает артефакт, запускает тесты, деплоит в production.

День X+1: Критичный баг в production

Пользователи: Приложение не загружается!

Создаём hotfix ветку, срочно фиксим, finish hotfix. Версии обновлены: main: 2.0.1, develop получила 2.0.1 обновления.

8. Инструменты для Git Flow

8.1 git-flow extension

Установка: brew install git-flow (macOS), apt-get install git-flow (Ubuntu)

Использование:

git flow feature start my-feature
git flow feature finish my-feature
git flow release start 1.0.0
git flow release finish 1.0.0
git flow hotfix start 1.0.1
git flow hotfix finish 1.0.1

8.2 SourceTree (GUI)

GUI интерфейс для работы с Git Flow: кнопки Create Feature/Release/Hotfix, визуализация ветвей, встроенный diff viewer.

9. Проблемы и решения

Проблема 1: Конфликты при мержа

Решение: вручную разрешить конфликты, отредактировать файл, git add, git commit.

Проблема 2: Случайно удалили feature ветку

Решение: найти ветку в reflog, восстановить через git checkout -b.

Проблема 3: Нужно перебазировать ветку

Решение: git fetch origin, git rebase origin/develop, разрешить конфликты, git rebase --continue, git push --force-with-lease.

Лучшие практики Git Flow

  1. Используйте --no-ff для мержа: сохраняет историю ветвей
  2. Коротко живущие ветки: feature максимум 1 неделя
  3. Синхронизируйте develop регулярно: pulls перед началом работы
  4. Теги на master: каждый релиз должен быть помечен тегом
  5. Автоматизируйте: используйте CI/CD для проверок
  6. Code review: обязательный для всех PR
  7. Ясные имена веток: feature/user-authentication, hotfix/security-issue
  8. Правильно называйте коммиты: Feature:, Bugfix:, Hotfix:

Git Flow проверен временем и используется в больших проектах для управления сложностью разработки. Это обеспечивает порядок, позволяет работать нескольким разработчикам параллельно и организует релизы. Основной принцип: develop для разработки, main для production, разделение на feature/release/hotfix ветки для различных типов работ.

Как работал с GitFlow | PrepBro