Какой GitFlow был на прошлом месте работы?

GitFlow на предыдущем проекте

На предыдущем месте работы мы использовали модифицированный вариант классического GitFlow, адаптированный для iOS разработки в команде из 12+ разработчиков, работающей на нескольких продуктах (основное приложение и несколько внутренних библиотек). Этот подход сочетает строгую структуру веток с практиками Continuous Integration.

Основная структура веток

• main (ранее master): Ветка, соответствующая текущей версии в App Store. Каждый коммит здесь — это фактически готовый к публикации билд. Защищена правилами: прямой пулл-реквест невозможен, только через мердж релиз-ветки.
• develop: Основная ветка для интеграции новой функциональности. Все feature-ветки мержатся здесь. Именно с develop запускаются ночные билды и основная часть автотестов.
• feature/*: Ветки для разработки новых фич, эпиков или значительных изменений. Создаются от develop. Имя обычно содержит Jira-тикет (например, feature/PROJ-123-auth-redesign) или краткое описание. После завершения работы мержатся обратно в develop. Жизненный цикл короткий (обычно 1-3 недели), чтобы избежать долгого отклонения от основной линии разработки.
• release/*: Ветки для подготовки конкретной версии к публикации (например, release/2.5.0). Создаются от develop когда набор фич для версии готов. Здесь происходит финальное полирование: багфиксинг, тонкая настройка UI, локализация, последние тесты. Все изменения мержатся и в release/*, и обратно в develop. По окончании подготовки ветка мержится в main, и создается тег (например, v2.5.0).
• hotfix/*: Ветки для критических багов, обнаруженных в main (в уже опубликованной версии). Создаются от main. После исправления мержатся сразу в main и в develop, чтобы баг не вернулся. Сопровождаются немедленным новым билдом для App Store (например, v2.5.1).

Процесс и ключевые практики

// Пример скрипта для автоматического создания релиз-ветки и тега (использовался в Fastlane):
lane :create_release do |options|
  version = options[:version]
  # 1. Создать ветку release от develop
  sh "git checkout develop"
  sh "git pull"
  sh "git checkout -b release/#{version}"
  
  # 2. Обновить версию в проекте (Info.plist, podspecs)
  update_version_number(version: version)
  
  # 3. Запустить полную suite тестов
  run_tests(scheme: "MainApp")
  
  # 4. Запустить сборку для App Store
  build_app_store()
  
  # 5. Если все успешно — создать тег на текущем состоянии
  sh "git tag -a v#{version} -m 'Release #{version}'"
  sh "git push origin release/#{version}"
  sh "git push origin tags/v#{version}"
end

• Пулл-реквесты (PR) как обязательный этап: Любой мерж в develop, release/* или main осуществлялся только через PR на GitHub. Это обеспечивало code review, автоматический запуск CI (тесты, статический анализ SwiftLint, проверка на симуляторах и реальных устройствах), и явное одобрение от хотя бы одного коллеги.
• Интеграция с CI/CD (Jenkins + Fastlane): Каждый пулл-реквест автоматически запускал pipeline сборки, тестов и даже деплой на TestFlight для release/* веток. Это позволяло "проверять в железе" перед мержем.
• Четкие правила для develop: Мы избегали долгого существования больших feature-веток. Если фича требовала больше 3 недель, ее делили на подфичи. Это минимизировало риск конфликтов при мерже.
• Связь с таск-менеджером (Jira): Имена веток всегда содержали ID задачи. Это позволяло автоматически связывать коммиты с тикетом и видеть историю в Jira.

Адаптация для iOS специфики

• Контроль версий зависимостей: В release/* ветках фиксировались версии CocoaPods (Podfile.lock) и Swift packages, чтобы билд в магазине был полностью воспроизводимым.
• Отдельные ветки для библиотек: Для внутренних iOS библиотек (модулей) использовался аналогичный flow, но их main ветка мержилась в develop основного приложения как обновление зависимости, а их релизы синхронизировались с релизами приложения.
• Хотфиксы для критических крешей: Процесс hotfix/* был оптимизирован для скорости — минимальный review, но максимальный набор автотестов. Часто хотфикс сопровождался параллельным созданием ветки fix/* от develop для того же бага, чтобы не забыть внести исправление в основную разработку.

Итог: Этот GitFlow обеспечивал нам стабильность main ветки (публичные версии), гибкость разработки в develop и feature-ветках, и контролируемый процесс выпуска версий через релиз-ветки. Главная ценность — в сочетании структуры с автоматизацией и культурой code review, что значительно снижало количество регрессий и конфликтов в коде.