Web Analytics Made Easy - StatCounter

Введение

Зачем Git Flow

Зачем нужен Git Flow, когда уже есть просто Git? Дело в том, что процесс разработки не оригинален по структуре вне зависимости от того пишите вы мобильное приложение (речь не про крупные приложения и системы в разработки которых и сам Git не востребован) или интернет-сайт: есть ветки для реализации отдельных особенностей и формирование на их основе релизов. Даже операции над ветками производятся одни и те же.

Консоль, GUI или GUI + Git Flow?

Как угодно, как привыкли. Общая идеология может реализовывать как через привычные консольные команды работы с репозиторием Git, так и через графический интерфейс как имеющий отдельные команды Git Flow так и без них. Подробнее читаем в Графические интерфейсы Git.

Окружение

Мы работаем в среде Atlassian: репозиторий - Bitbucket, управление задачами - Jira. Ветки разработки строго привязываются к задачам, без задач веток нет. Это касается даже hotfix. Это важно для формирования отчётности по трудозатратам отдельной задачи или спринта.

Суть Git Flow

Стандартизация названий веток

Винсент Дрисен предложил схему (редкий случай когда слово fremework вполне уместно) обработки веток. Естественно, без стандартизации их названий обрабатывать их нельзя. Ветки разработки новый свойств feachure, общая ветка разработки develop, ветка релизов и релиз-кандидатов release, ветка финальных релизов master и ветки пострелизных правок hotfix.

Pipelines и непрерывная разработка

С помощью pipelines слияние веток инициирует обновление содержимого удалённого сервера\площадки. Таким образом, если определённые ветки настроить на выгрузку то можно постоянно осуществлять выпуски версий проекта на выбранные серверы в автоматическом режиме. Ветка develop имеет одностороннюю синхронизацию по pipeline с внутренним сервером разработки, ветка release с демонстрационным сервером для заказчика. Синхронизация баз данных

Deploy

Деплой это процесс развёртывания приложения на целевой площадке заказчика. Так как у нас веб-разработка, то с готовы релизом никаких дополнительных действий, обычно, производить не нужно, кроме изменения конфигурации под целевой сервер заказчика. На данный момент диплой сводится к ручному переносу проекта на хостинг заказчика. Автоматизация этого процесса - дело будущего.

Общая схема

Git Flow

Ветки

Feachure

Ветка создаётся из ветки develop. Синтаксис названия feachure/ID_задачи, например feachure/GWS-63. Классификация ветки происходит по задаче. Ветка создаётся локально, на площадке с которой работает разработчик. В целом не важно какие у нее будут коммиты, важен лишь тот момент, когда разработчик считает, что работу нужно отправлять на проверку.

Тогда он сливает ветку с develop не удаляя, так как если её не примут, то она будет нужна для продолжения работ. Если используемый клиент Git поддерживает Git Flow то для этой операции будет отдельная кнопка как, например, в GitKraken.

После принятия задачи ветка сливается с удалением так как не нужно раздувать общий репозиторий промежуточной информацией.

После выгрузки ветки для проверки в develop нужно обязательно проверять видны ли там необходимые изменения. Develop

Основная ветка разработки. Создаётся из master. В ней обязательно присутствуют все изменения проекта, включая hotfix. Имеет одностороннюю синхронизацию с dev-сервером через pipeline. Служит проверкой совместимости производимых правок и разрешения возникающих конфликтов. Заказчик не имеет доступа на тестовый сервер. Release

Ветка релиз-кандидатов, которые выгружаются в неё для отправки на демонстрационный (stage по-английски «сцена») сервер доступный заказчику. После проверки релиз-кандидат уходит в доработку либо становится релизом.

Master

Ветка окончательных релизов. Имеет одностороннюю синхронизацию с целевым сервером заказчика.

В условиях не готовности алгоритмов диплоя выгрузка осуществляется на stage-сервер.

Hotfix

Если нужно внести срочные правки в релиз, то они реализуются веткой hotfix, которая начинается из ветки master, обновляется в нее, но сливается по принятию в develop. Это необходимо для того, чтобы в последующей разработке не потерялись изменения на релизе. Синтаксис hotfix/ID_задачи.

После пострелизной правки к имени версии релиза добавляется на конце HF#, где HF значит Hot Fix, а # - номер правки. В описание релиза добавляется запись о правке и номере задачи к которой она относилась.

Серверы

Develop

Сервер/площадка разработчиков. С нее делаются регулярные резервные копии проекта.

Stage

Сервер/площадка демонстрации заказчику. Находится на том же хостинге, что и Dev-сервер.

Local

Персональная площадка разработчика.