Блог о программировании

Модели ветвления git. Gitflow

 11 февраля 2018 г. 17:01

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

Как это работает gitflow. Начальное состояние

В самом начале в master-ветке делается какой-то начальный коммит. Master-ветка содержит код, который всегда готов быть отправлен на рабочку. Обычно каждому обновлению кода ветки master присваивают релизный номер в теге. Таким образом, master-ветка содержит все релизы проекта. Так, первому коммиту можно присвоить тег v0.0.1 и считать, что это отправная точка проекта. После этого от master fork’ается ветка с говорящим названием develop. В develop-ветке находятся последние наработки по проекту, которые напрямую не коммитятся в develop. Все изменения кода выполняются в так называемых feature-ветках - для каждой фичи своя отдельная ветка.

gitflow. Ветки с фичами

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

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

gitflow. Готовим release

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

Когда команда решает, что все баги отловлены, а release-ветка содержит достаточно стабильный код для релиза, ветка вливается в master. Последнему коммиту в master-ветке присваивается тег с релизным номером. Также нужно не забыть влить release-ветку в develop, поскольку при подготовке релиза, в release могли быть внесены изменения, которые должны появиться в develop.

gitflow. Слили release в master

Когда код из master попадет на боевой стенд – релиз можно считать состоявшимся.

Даже на в коде релиза остаются не закрытые баги. В случае появления такой ситуации, фикс бага аналогичен разработке новой фичи: создается новая ветка из master-ветки, обычно она именуется hotfixes/<название_ветки_фикса>. Далее происходит правка кода, закрывается баг. Ветка, в которой делались изменения, вливается в master, а также в develop-ветку. Таким образом, баг правится как в ветке, которая выгружается на боевой стенд, так и в ветке, в которой ведется основная разработка.

gitflow. Готовим hotfix Итог

Gitflow представляет из себя отличную и довольно таки удобную модель ветвления.

Когда проект рассчитан на длительное время со сколько-нибудь постоянным циклом релизов, и при этом, проект не завязан жестко на другой активно разрабатываемый проект – такая ситуация является наиболее подходящим случаем использования gitflow.

В gitflow имеются две основные ветки – master и develop. Master-ветка содержит код, который всегда готов быть отправлен на рабочку. Он стабильный, в нем минимум багов. Develop-ветка, напротив, содержит менее стабильный код, нежели master, однако этот код наиболее актуальный.

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

Для удобства работы с данной моделью ветвления была создана утилита gitflow, которая является консольной надстройкой над git. Она позволяет работать с git в терминах описанной модели ветвления. Приблизительно так выглядит работа с ней:

# Создание веток master/developer/release/hotfix
$ git flow init

# Начинаем работать над функционалом feature1 (ответвление от develop)
$ git flow feature start feature1
# делаем изменения
$ git add ...изменения...
$ git commit -m "изменения для feature1"

# Эта команда сделает слияние feature1 с develop и удалит ветку
$ git flow feature finish feature1

# Давайте начнём работу над релизом
$ git flow release start release1
# делаем изменения
$ git add ...изменения...
$ git commit -m "release1"

# Эта команда сделает слияние release1 с master
$ git flow release finish release1
Ссылки

Оригинал статьи на английском (с примерами команд git)

Перевод оригинала (с примерами команд git)

Теги:  workflow  git  git workflow  gitflow 

Поделиться статьей

Оставить комментарий