Рабочий процесс Gitflow Workflow

Git-flow — это устаревшая версия рабочего процесса Git, в свое время ставшая принципиально новой стратегией управления ветками в Git. Популярность Git-flow стала снижаться под влиянием магистральных рабочих процессов, которые на сегодня считаются предпочтительными для современных схем непрерывной разработки ПО и применения DevOps. Кроме того, Git-flow не слишком удобно применять в процессах CI/CD. В этой публикации приводится описание Git-flow для истории.

Что собой представляет Git-flow?

Git-flow — альтернативная модель ветвления Git, в которой используются функциональные ветки и несколько основных веток. Эта модель была впервые опубликована и популяризована Винсентом Дриссеном на сайте nvie. По сравнению с моделью магистральной разработки, в Git-flow используется больше веток, каждая из которых существует дольше, а коммиты обычно крупнее. В соответствии с этой моделью разработчики создают функциональную ветку и откладывают ее слияние с главной магистральной веткой до завершения работы над функцией. Такие долгосрочные функциональные ветки требуют тесного взаимодействия разработчиков при слиянии и создают повышенный риск отклонения от магистральной ветки. В них также могут присутствовать конфликтующие обновления.

Git-flow можно использовать для проектов, в которых запланирован цикл релизов и реализуется характерная для DevOps методика непрерывной поставки. В этом рабочем процессе используются понятия и команды, которые были предложены в рамках рабочего процесса с функциональными ветками. Однако Git-flow привносит новые специфические роли для разных веток и определяет характер и частоту взаимодействия между ними. Помимо функциональных веток в рамках этого рабочего процесса используются отдельные ветки для подготовки, поддержки и регистрации релизов. При этом вы по-прежнему можете пользоваться преимуществами рабочего процесса с функциональными ветками, такими как запросы pull, изолированные эксперименты и эффективное командное взаимодействие.

Начало работы

Gitflow — это лишь методика работы с Git; в ней определяется, какие виды веток необходимы проекту и как выполнять слияние между ними. Ниже мы познакомимся с назначением веток. Набор инструментов git-flow представляет собой отдельную утилиту командной строки, которая требует установки. Процесс установки прост. Пакеты команд git-flow доступны для многих операционных систем. В системах OS X можно выполнить команду brew install git-flow. Если вы используете Windows, вам нужно загрузить и установить git-flow. После установки решения git-flow необходимо выполнить команду git flow init, чтобы использовать его в проекте. Этот набор инструментов играет роль обертки Git. Команда git flow init является расширением стандартной команды git init и не вносит изменений в репозиторий помимо создания веток.

Порядок действий

Ветка разработки и главная ветка

В этом рабочем процессе для регистрации истории проекта вместо одной ветки main используются две ветки. В главной ветке main хранится официальная история релиза, а ветка разработки develop предназначена для объединения всех функций. Кроме того, для удобства рекомендуется присваивать всем коммитам в ветке main номер версии.

Первый шаг рабочего процесса заключается в создании ветки develop от стандартной ветки main. Разработчику будет проще создать пустую ветку develop локально и отправить ее на сервер.

git branch develop
git push -u origin develop

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

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

$ git flow init


Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]


How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []


$ git branch
* develop
 main

Функциональные ветки (feature)

Под каждую новую функцию нужно выделить собственную ветку, которую можно отправить в центральный репозиторий для создания резервной копии или совместной работы команды. Ветки feature создаются не на основе main, а на основе develop. Когда работа над функцией завершается, соответствующая ветка сливается с веткой develop. Функции не следует отправлять напрямую в ветку main.

Обратите внимание, что комбинация веток feature с веткой develop фактически представляет собой рабочий процесс с функциональными ветками. Но рабочий процесс Gitflow на этом не заканчивается.

Как правило, ветки feature создаются на основе последней ветки develop.

Создание функциональной ветки

Без использования расширений git-flow:

git checkout develop
git checkout -b feature_branch

С использованием расширений git-flow:

git flow feature start feature_branch

Продолжайте работу с Git как обычно.

Окончание работы с функциональной веткой

После завершения работы над функцией следует объединить ветку feature_branch с develop.

Без использования расширений git-flow:

git checkout develop
git merge feature_branch

С использованием расширений git-flow:

git flow feature finish feature_branch

Ветки выпуска (release)

Когда в ветке develop оказывается достаточно функций для выпуска (или приближается назначенная дата релиза), от ветки develop создается ветка release. Создание этой ветки запускает следующий цикл релиза, и с этого момента новые функции добавить больше нельзя — допускается лишь исправление багов, создание документации и решение других задач, связанных с релизом. Когда подготовка к поставке завершается, ветка release сливается с main и ей присваивается номер версии. Кроме того, нужно выполнить ее слияние с веткой develop, в которой с момента создания ветки релиза могли возникнуть изменения.

Благодаря тому, что для подготовки выпусков используется специальная ветка, одна команда может дорабатывать текущий выпуск, в то время как другая команда продолжает работу над функциями для следующего. Это также позволяет разграничить этапы разработки (например, можно без труда посвятить неделю подготовке к версии 4.0 и действительно увидеть это в структуре репозитория).

Создание веток release — это еще одна простая операция ветвления. Как и ветки feature, ветки release основаны на ветке develop. Создать новую ветку release можно с помощью следующих команд.

Без использования расширений git-flow:

git checkout develop
git checkout -b release/0.1.0

При использовании расширений git-flow:

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

Когда подготовка к поставке завершается, релиз сливается с ветками main и develop, а ветка release удаляется. Важно слить ее с веткой develop, поскольку в ветку release могли добавить критические обновления, которые должны быть доступны для новых функций. Если в вашей организации уделяют повышенное внимание проверке кода, это идеальное место для выполнения запроса pull.

Для завершения работы в ветке release используйте следующие команды:

Без использования расширений git-flow:

git checkout main
git merge release/0.1.0

Или при использовании расширений git-flow:

git flow release finish '0.1.0'

Ветки исправления (hotfix)

Ветки сопровождения или исправления (hotfix) используются для быстрого внесения исправлений в рабочие релизы. Ветки hotfix очень похожи на ветки release и feature. Отличие заключается в том, что они создаются на основе main, а не develop. Это единственная ветка, которую нужно обязательно создавать напрямую от main. Как только исправление завершено, эту ветку следует слить с main и develop (или текущей веткой release), а ветке main присвоить обновленный номер версии.

Благодаря специальной ветке для исправления ошибок команда может устранять проблемы, не прерывая остальную часть рабочего процесса и не дожидаясь следующего цикла релиза. Ветки сопровождения можно рассматривать как специальные ветки release, которые работают непосредственно с main. Ветку hotfix можно создать с помощью следующих команд.

Без использования расширений git-flow:

git checkout main
git checkout -b hotfix_branch

При использовании расширений git-flow:

$ git flow hotfix start hotfix_branch

По завершении работы с веткой hotfix ее сливают с main и develop (как и в случае с веткой release).

git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

$ git flow hotfix finish hotfix_branch

Пример

Далее показан полный цикл работы с функциональной веткой (предполагается, что у нас есть репозиторий с веткой main).

git checkout main
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branch

Помимо работы с ветками feature и release, продемонстрируем работу с веткой hotfix:

git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branch

Резюме

В этой статье мы рассмотрели модель работы Gitflow. Gitflow — лишь одна из многих методологий работы с Git, доступных вам и вашей команде.

Ключевые идеи, которые нужно запомнить о Gitflow:

• Данная модель отлично подходит для организации рабочего процесса на основе релизов.
• Работа по модели Gitflow предусматривает создание специальной ветки для исправления ошибок в рабочем релизе.
  

Последовательность действий при работе по модели Gitflow:

1. Из ветки main создается ветка develop.
2. Из ветки develop создается ветка release.
3. Из ветки develop создаются ветки feature.
4. Когда работа над веткой feature завершается, она сливается в ветку develop.
5. Когда работа над веткой release завершается, она сливается с ветками develop и main.
6. Если в ветке main обнаруживается проблема, из main создается ветка hotfix.
7. Когда работа над веткой hotfix завершается, она сливается с ветками develop и main.

Рекомендуем ознакомиться с моделью рабочего процесса с форками или посетить нашу страницу сравнения рабочих процессов.