Gitflow: методология организации работы с инкрементальным хранилищем типа Git
Что такое Gitflow?
Gitflow - это альтернативная модель ветвления Git, предполагающая использование функциональных веток и нескольких основных веток. Впервые она была опубликована и стала популярной благодаря Винсенту Дриссену в nvie. По сравнению с разработкой на основе ствола, Gitflow имеет многочисленные, более долгоживущие ветви и более крупные коммиты. В соответствии с этой моделью разработчики создают функциональную ветку и откладывают ее слияние с основной веткой ствола до завершения работы над функцией. Такие долгоживущие ветки требуют более тесного взаимодействия для слияния и имеют более высокий риск отклонения от магистральной ветки. Кроме того, в них могут появляться конфликтующие обновления.
Gitflow можно использовать в проектах с запланированным циклом выпуска и для лучшей практики DevOps - непрерывной доставки. Этот рабочий процесс не добавляет никаких новых концепций или команд сверх того, что требуется для рабочего процесса Feature Branch Workflow. Вместо этого он назначает совершенно конкретные роли различным ветвям и определяет, как и когда они должны взаимодействовать. В дополнение к функциональным веткам отдельные ветки используются для подготовки, сопровождения и записи релизов. Разумеется, при этом вы получаете все преимущества Feature Branch Workflow: запросы на исправление, изолированные эксперименты и более эффективную совместную работу.
Зачем GitFlow
Зачем нужен GitFlow, когда уже есть просто Git? Дело в том, что процесс разработки не оригинален по структуре вне зависимости от того пишите вы мобильное приложение (речь не про крупные приложения и системы в разработки которых и сам Git не востребован) или интернет-сайт: есть ветки для реализации отдельных особенностей и формирование на их основе релизов. Даже операции над ветками производятся одни и те же.
Консоль, GUI или GUI + GitFlow?
Как угодно, как привыкли. Общая идеология может реализовывать как через привычные консольные команды работы с репозиторием Git, так и через графический интерфейс как имеющий отдельные команды GitFlow так и без них. Подробнее читаем в Графические интерфейсы Git.
Окружение
Мы работаем в среде Atlassian: репозиторий - Bitbucket, управление задачами - Jira. Ветки разработки строго привязываются к задачам, без задач веток нет. Это касается даже hotfix. Это важно для формирования отчётности по трудозатратам отдельной задачи или спринта.
Суть GitFlow
Стандартизация названий веток
Винсент Дрисен предложил схему (редкий случай когда слово fremework вполне уместно) обработки веток. Естественно, без стандартизации их названий обрабатывать их нельзя. Ветки разработки новый свойств feachure, общая ветка разработки develop, ветка релизов и релиз-кандидатов release, ветка финальных релизов master и ветки пострелизных правок hotfix.
Pipelines и непрерывная разработка
С помощью pipelines слияние веток инициирует обновление содержимого удалённого сервера\площадки. Таким образом, если определённые ветки настроить на выгрузку то можно постоянно осуществлять выпуски версий проекта на выбранные серверы в автоматическом режиме. Ветка develop имеет одностороннюю синхронизацию по pipeline с внутренним сервером разработки, ветка release с демонстрационным сервером для заказчика.
Синхронизация баз данных
Deploy
Деплой это процесс развёртывания приложения на целевой площадке заказчика. Так как у нас веб-разработка, то с готовы релизом никаких дополнительных действий, обычно, производить не нужно, кроме изменения конфигурации под целевой сервер заказчика. На данный момент диплой сводится к ручному переносу проекта на хостинг заказчика. Автоматизация этого процесса - дело будущего.
Общая схема
Ветки
Feachure
Ветка создаётся из ветки develop. Синтаксис названия feachure/ID_задачи, например feachure/GWS-63. Классификация ветки происходит по задаче. Ветка создаётся локально, на площадке с которой работает разработчик. В целом не важно какие у нее будут коммиты, важен лишь тот момент, когда разработчик считает, что работу нужно отправлять на проверку.
Тогда он сливает ветку с develop не удаляя, так как если её не примут, то она будет нужна для продолжения работ. Если используемый клиент Git поддерживает GitFlow то для этой операции будет отдельная кнопка как, например, в GitKraken.
После принятия задачи ветка сливается с удалением так как не нужно раздувать общий репозиторий промежуточной информацией.
После выгрузки ветки для проверки в develop нужно обязательно проверять видны ли там необходимые изменения.
Develop
Основная ветка разработки. Создаётся из master. В ней обязательно присутствуют все изменения проекта, включая hotfix. Имеет одностороннюю синхронизацию с dev-сервером через pipeline. Служит проверкой совместимости производимых правок и разрешения возникающих конфликтов. Заказчик не имеет доступа на тестовый сервер.
Release
Ветка релиз-кандидатов, которые выгружаются в неё для отправки на демонстрационный (stage по-английски «сцена») сервер доступный заказчику. После проверки релиз-кандидат уходит в доработку либо становится релизом.
Master
Ветка окончательных релизов. Имеет одностороннюю синхронизацию с целевым сервером заказчика. В условиях не готовности алгоритмов диплоя выгрузка осуществляется на stage-сервер.
Hotfix
Если нужно внести срочные правки в релиз, то они реализуются веткой hotfix, которая начинается из ветки master, обновляется в нее, но сливается по принятию в develop. Это необходимо для того, чтобы в последующей разработке не потерялись изменения на релизе. Синтаксис hotfix/ID_задачи.
После пострелизной правки к имени версии релиза добавляется на конце HF#, где HF значит Hot Fix, а # - номер правки. В описание релиза добавляется запись о правке и номере задачи к которой она относилась.