За 9 лет в своей работе я часто сталкивался с проблемой, как лучше организовать процессы разработки, чтобы они были понятны команде и эффективны для продукта. Мне повезло, ведь это всегда вызывало у меня интерес, потому что разработка — это не только написание кода, но и умение правильно им управлять.
Представьте, вы работаете над проектом с командой, каждый пишет код, добавляет функциональность, исправляет ошибки, но в какой-то момент все эти действия начинают мешать друг другу. Без должной структуры процессы могут становиться хаотичными, что приводит к путанице, конфликтам и потере времени, и, для клиентов самое главное, денег.
Сегодня мы рассмотрим подход к стандартизации разработки в команде — Git Flow. Эта модель разветвления, предложенная Винсентом Дриссеном в 2010 году, стала популярной среди команд разработчиков из-за её чёткой структуры и удобства в управлении процессами.
Основная стратегия Git Flow — это использование ветвей для работы над проектом, которая обеспечивает команде помощь в распределении задач, упрощает релизы/обновление и добавление новых функций в проект.
Если описывать очень просто — Git Flow изолирует разработку определённых функций в отдельные ветви, что помогает каждому члену команды работать независимо друг от друга.
Далее мы рассмотрим, как это работает:
1️⃣ ОСНОВНАЯ ВЕТВЬ MASTER
Ветка master является стволом нашего проекта, от которого мы идём и где у нас сохраняется вся история и хронология наших стабильных релизов.
Мы локально можем создать пустую ветвь develop и отправить её на сервер GitHub.
2️⃣ ВЕТВЬ DEVELOP
От ветви master мы создаём ветвь develop, в которой будет вестись вся разработка и хронология нашего проекта с точки зрения разработки.
Здесь у нас есть важный момент: наша ветвь develop никогда не должна пересекаться с нашим стволом master, об этом мы поговорим в дальнейшем.
- Создание ветви develop
git branch develop*Загрузка ветки на сервер GitHub
git push -u origin developДругие же разработчики в команде должны клонировать основной репозиторий (ветвь master) и создать локальную копию ветви develop.
3️⃣ ВЕТВИ FEATURE
Эту ветку мы используем для разработки отдельных функций или изменений в проект. Feature создаётся из ветки develop и после завершения разработки снова возвращается в ветвь develop.
*Переключение на ветку develop
git checkout develop- Создание ветки feature
git checkout -b feature/назва функції*После завершения работы над функцией мы объединяем ветвь feature с ветвью develop.
git checkout develop
git merge feature/назва функції4️⃣ ПОДГОТОВКА К РЕЛИЗУ
Когда весь наш функционал уже готов и добавлен в ветку develop, мы создаём ветвь release.
Важный момент! После создания ветки release уже нельзя создавать и объявлять новые функции, в ней мы можем исправлять ошибки, обновлять документацию, оптимизировать код без добавления нового функционала.
*Переключение на ветку develop
git checkout develop- Создание ветки release
git checkout -b release/V2.15️⃣ ОБЪЕДИНЕНИЕ ВЕТВЕЙ
После тестирования, добавления документации мы убеждаемся, что наша версия стабильна, и только после этого мы можем её объединить с веткой master, чтобы синхронизировать все изменения.
*Переключение на ветку master и слияние release
git checkout master
git merge release/V2.1После этого мы удаляем нашу ветвь release и продолжаем работу в develop. Наша команда может дальше работать, пока мы занимались релизом, поэтому необходимо не просто удалить, но ещё и объединить release и develop, чтобы мы имели возможность в дальнейшем работать с самыми актуальными данными и функциями.
*Переключение на ветвь develop и слияние release
git checkout develop
git merge release/V2.1*Удаление ветки release
git branch -D release/V2.1Завершается ли после этого работа?
Нет, потому что могут возникать проблемы, которые нужно решать быстро здесь и сейчас, и для этого мы используем ветку hotfix о которой дальше поговорим.
6️⃣ HOTFIX ИЛИ ИСПРАВЛЕНИЕ ОШИБОК
Прежде всего, нужно понимать, что ветвь hotfix мы создаём только в том случае, когда наш проект был выпущен, и у нас уже после возникли проблемы.
Ветвь создаётся только от основной нашей ветви master.
*Переключение на основную ветку master
git checkout master- Создание новой ветки hotfix
git checkout -b hotfix7️⃣ ОБЪЕДИНЕНИЕ ВСЕХ ВЕТВЕЙ
После всех исправлений мы снова объединяем hotfix с master, после чего удаляем. Это мы делаем для того, чтобы синхронизировать все исправления и дальше работать с самой актуальной версией нашего проекта.
*Переключение на ветку master и слияние hotfix
git checkout master
git merge hotfixЭто переключает нас на ветку master и сливает изменения из ветки hotfix.
Рекомендация: после слияния (особенно в ветку master) следует убедиться, что всё работает корректно, и произвести пуш изменений в отдалённый репозиторий.
*Переключение на ветку develop и слияние hotfix
git checkout develop
git merge hotfixЭто переключает нас на ветку develop и сливает изменения из ветки hotfix.
*Удаление hotfix
git branch -D hotfixКРАТКОЕ РЕЗЮМИРОВАНИЕ РАБОТЫ С GIT FLOW:
- Создание ветки develop — делается для истории разработки.
- Создание ветки feature — реализуем новые функции (от develop).
- Объединение feature & develop — после завершения работы над новыми функциями.
- Создание ветви release — подготовка к релизу (от develop), объединяем с master & develop и удаляем.
- Создание ветки hotfix — исправление ошибок после релиза (от master), объединяем её с master&develop и удаляем!
Теперь, когда мы разобрались, как работает Git Flow, мы можем рассмотреть его преимущества и недостатки.
ПРЕИМУЩЕСТВА
- Чёткая структура: каждый этап нашей разработки имеет свою специальную ветвь, упрощающую процесс разработки и управления.
- Безопасность: наша ветвь master всегда содержит стабильный код.
- Лёгкость в исправлении ошибок: ветвь hotfix позволяет безопасно и быстро решать проблемы после релиза.
- Гибкость: изоляция разработки, позволяющая работать членам команды независимо друг от друга.
НЕДОСТАТКИ
- Чрезмерная сложность для небольших проектов: для проектов с коротким жизненным циклом или поддержкой использования Git Flow может быть лишним (но это не часто случается).
- Проблема с merge в больших проектах: во время интенсивной разработки в больших командах могут возникать конфликты во время merge.
- Снижение скорости разработки: в больших проектах нужно проходить все этапы при разработке, и поэтому может увеличиваться время на саму разработку.
ВЫВОД
Итак, если подытожить, то Git Flow — это как помощник для команды разработчиков, где всё разложено по полочкам.
Все всегда знают, где что хранится: стабильный код в master, разработка в develop, новые фичи по отдельности, а исправление критических багов — ещё в другой ветке. Это реально круто, когда проект большой и над ним работает много людей, потому что исчезает хаос и неразбериха.
Разумеется, есть свои минусы. К примеру, если проект маленький, то вся эта структура может быть немного «многовато». Но в серьёзных проектах, где важно, чтобы всё было чётко и без сюрпризов, Git Flow спасает.
Конечно, бывает, что при слиянии ветвей возникают конфликты, и иногда это немного тормозит процесс, но согласитесь — лучше потратить немного больше времени на структурирование, чем потом разгребать хаос.
Итак, если работаете в команде и ищете решение, которое может упростить жизнь всей команде, то Git Flow — это реально классный выбор.
