Кратко о git-flow

Git-flow — наиболее популярная методология разработки проектов с использованием git.

Зачем нам вообще нужны какие-то методологии для работы с git?

Дело в том, что сам git не привязывает нас к какому-либо определённому способу разработки, и каждый разработчик, в теории, может работать с контролем версий так, как он хочет. Чтобы в таких условиях не погрузить наш репозиторий в хаос, нам нужно придумать и донести до всех разработчиков некий единый стандарт для работы с контролем версий в проекте.

Git-flow даёт нам готовый стандарт проверенный временем и уже известный многим разработчикам.

В то же время, нужно понимать, что методология git-flow не является единственно верной и на 100% универсальной. В Вашем проекте может существовать собственный подход к работе с git. Однако, если вы работаете или собираетесь работать с git в команде, то стоит знать о том, что такое git-flow и в чём его особенности.

И так, что же нам стоит знать о git-flow?

Суть ветвления в git-flow

Всего в git-flow существует 5 типов веток, каждый из которых несёт определённую функциональную нагрузку.

Ветка develop

Ветка существует на протяжении всего процесса разработки. В данную ветку попадает стабильный код новых фич и багфиксов.

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

Ветки feature-*

Временные ветки, которые создаются для каждой нетривиальной фичи.

Каждая ветка feature отделяется от develop и мержится обратно в него. После завершения работы над фичей и финального мержа в develop, ветка удаляется. При мерже ветки в develop не должен использоваться fast-forward (флаг –no-ff).

Имя ветки должно соответствовать имени разрабатываемой фичи, например “feature-gamecenter-integration”. В некоторых проектах префикс “feature-” опускается (тогда любая ветка без префикса — это ветка feature).

Ветка master

Ветка, куда поступают самые стабильные изменения, которые идут в релиз. Существует на протяжении всего процесса разработки.

В ветку master мержатся только изменения из веток release и hotfix. На каждый такой мерж создаётся тег с именем версии. Полный запрет использования fast-forward при мерже в ветку (флаг –no-ff).

По сути, в самой ветке не должно быть никаких коммитов, кроме коммитов мержей, каждый из которых должен быть отмечен тегом версии.

Ветки release-*

Временные ветки, создаваемые для подготовки новой версии к релизу. В эти ветки попадают правки багов и настройки перед релизом.

Ветка выходит из develop и может мержится в develop по ходу подготовки версии. Как только работа над версией заканчивается, происходит финальный мерж ветки в master и develop, после чего ветка удаляется, а коммиту мержа в master присваивается тег новой версии.

Имя ветки должно соответствовать выпускаемой версии, например “release-1.4”.

Ветки hotfix-*

Временные ветки hotfix-* создаются для правки критических проблем в релизной версии.

Ветка отходит от master и по завершению правок багов мержится обратно. Сама ветка после этого удаляется, а коммиту мержа в master присваивается тег новой версии.

Именем ветки обычно является новая версия с учётом версии фикса, например “hotfix-1.4.1” (первый хотфикс версии 1.4).

Подробнее про ветвление в git-flow можно узнать из оригинальной статьи автора методологии или из её перевода на русский язык.

Инстументы с поддержкой git-flow

По сути нам нет необходимости в каких-то особенных инструментах для поддержания процессов разработки, все действия могут быть выполнены из практически любой графической оболочки над git, либо из командной строки.

Однако, есть удобное расширение для git, которое позволяет немного ускорить ежедневную работу по данной методологиии за счёт уменьшения количества вводимых команд в консоли и работы непосредственно на уровне абстракций git-flow.

Так же, git-flow поддерживается из коробки некоторыми популярными графическими оболочками такими как SourceTree и SmartGit.

Как в случае консольного расширения, так и в случае графических клиентов, мы работаем с более понятными командами вроде “Start Feature” и “Finish Feature”, что позволяет проще смотреть на процесс разработки.

Git-flow и непрерывная интеграция

При разработке с использованием git-flow, одновременно существует две стабильные ветки, которые можно использовать для сборки билдов или выкладки кода на сервер: это ветки master и develop.

Сборки из ветки master можно собирать сразу по поступлении новых изменений. Любые новые правки в этой ветке — это стабильный production-код, который можно выкладывать на сервер (в случае разработки веб-ресурса) либо собирать в релизный бинарник.

Версии собранные из ветки master должны в обязательном порядке подвергаться всем существующим в проекте автоматизированным тестам.

Из ветки develop можно собирать ночные сборки (для тестирования) либо, по мере разработки, можно выкладывать код из этой ветки на тестовый сервер (в случае разработки веб-ресурса).

На версиях собранных из ветки develop следует прогонять unit-тесты.

Когда не стоит применять git-flow

Во первых, git-flow достаточно сложная методология, расчитанная на большие проекты. Если проект относительно небольшой и над ним работает команда всего из 3-4 человек, то применение git-flow может только усложнить процесс разработки.

Во вторых, git-flow в чистом виде применим только в тех случаях, когда в процессе разработки присутствует такое понятие как “релиз”. Если изменения публикуются в продакшн по мере разработки, то смысла применять git-flow тоже нет.

В обоих случаях, можно либо взять git-flow, отказавшись от некоторых типов веток (master, release, hotfix), либо выбрать другую методологию.