Рабочий процесс с функциональными ветками Git

Основная идея рабочего процесса с функциональными ветками заключается в том, что разработка всех функций должна происходить в специальной ветке, а не в ветке master. Такое обособление позволяет нескольким разработчикам с легкостью работать над конкретной функцией, не затрагивая основную базу кода. Кроме того, благодаря этому исключены нарушения кода в ветке master, что является важным преимуществом для среды с непрерывной интеграцией.

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

Составной рабочий процесс Git с функциональными ветками может использоваться другими высокоуровневыми рабочими процессами Git, которые рассматриваются на странице обзора рабочих процессов Git. Рабочий процесс Git с функциональными ветками ориентирован на модель ветвления кода и представляет собой рамочную систему для создания веток и управления ими. Другие рабочие процессы больше ориентированы на работу с репозиторием. Рабочий процесс Git с функциональными ветками можно интегрировать в другие рабочие процессы. В частности рабочий процесс Gitflow и рабочий процесс Git с форками традиционно используют рабочий процесс Git с функциональными ветками в своих моделях ветвления кода.

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


В рабочем процессе с функциональными ветками используется центральный репозиторий, а ветка master отражает официальную историю проекта. Вместо создания коммитов напрямую в локальной ветке master, разработчики создают новую ветку каждый раз при начале работы над новой функцией. Функциональные ветки должны иметь описательные имена (например, «анимированные-элементы-меню» или «задача-1061»). Каждая ветка должна быть предназначена строго для одной цели. Технически Git не различает ветку master и функциональные ветки, поэтому разработчики могут редактировать, индексировать и подтверждать изменения функциональных веток.

Кроме того, функциональные ветки можно (и нужно) отправлять в центральный репозиторий. Это позволяет работать над функцией совместно с другими разработчиками, не затрагивая официальный код. Поскольку master —это единственная «особая» ветка, хранение нескольких функциональных веток в центральном репозитории не представляет сложностей. Разумеется, это еще и удобный способ резервного копирования локальных коммитов. Ниже приводится пошаговый обзор жизненного цикла функциональной ветки.

Начало работы с главной веткой

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

 git checkout master git fetch origin git reset --hard origin/master

Эта команда переключает репозиторий на ветку master, осуществляет pull последних коммитов и сбрасывает локальную копию ветки master, чтобы она соответствовала последней версии.

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

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

git checkout -b new-feature

Эта команда выполняет переключение на ветку new-feature, основанную на ветке master. Флаг -b указывает Git на необходимость создания ветки, если она еще не существует.

Обновление, добавление, коммит и отправка изменений

В этой ветке можно выполнять редактирование, индексирование и отправку изменений обычным способом, используя неограниченное количество коммитов для формирования функции. Работайте над этой функцией и делайте необходимые коммиты, как обычно при использовании Git. Завершив работу, отправьте коммиты, чтобы обновить функциональную ветку в Bitbucket.

 git status git add  git commit

Отправка функциональной ветки в удаленный репозиторий

Желательно отправлять функциональную ветку в центральный репозиторий. Это удобный способ резервного копирования при совместной работе с другими разработчиками: так они получают возможность просматривать коммиты в новой ветке.

git push -u origin new-feature

Эта команда отправляет ветку new-feature в центральный репозиторий (источник), и она посредством флага -u добавляется в качестве удаленной отслеживаемой ветки. После настройки отслеживаемой ветки можно вызвать git push без каких-либо параметров для автоматической отправки ветки new-feature в центральный репозиторий. Для получения отзыва о новой функциональной ветке создайте запрос pull в системе управления репозиториями, например Bitbucket Cloud или Bitbucket Server. Затем можно добавить проверяющих и убедиться, что все работает правильно, прежде чем выполнять слияние.

Исправление функции по отзывам

На этом этапе коллеги комментируют и утверждают отправленные коммиты. Исправьте функцию по их отзывам локально, а затем сделайте коммит и отправьте рекомендованные изменения в Bitbucket. Обновления отобразятся в запросе pull.

Слияние запроса pull

Если другие пользователи вносили изменения в репозиторий, перед слиянием может потребоваться разрешение конфликтов слияния. Если ваш запрос pull утвержден и не содержит конфликтов, вы можете добавить код в ветку master. Выполните слияние из запроса pull в Bitbucket.

Запросы pull

Использование веток не только изолирует разработку функций, но и позволяет обсуждать изменения с помощью запросов pull. Когда работа над функцией завершена, ее слияние с веткой master происходит не сразу. Сначала разработчик отправляет функциональную ветку на центральный сервер и отправляет запрос pull на слияние своего дополнения с веткой master. Это позволяет другим разработчикам проверить изменения до того, как они будут включены в основную базу кода.

Главное преимущество запросов pull — возможность проверки кода, но изначально они были задуманы как способ обсуждения кода. Запрос pull можно использовать для обсуждения конкретной ветки на раннем этапе в процессе разработки. Например, если разработчику требуется помощь с определенной функцией, достаточно отправить запрос pull. Заинтересованные стороны автоматически получат уведомление и смогут просмотреть вопрос разработчика рядом с соответствующими коммитами.

После принятия запроса pull процедура публикации функции во многом совпадает с аналогичной процедурой в централизованном рабочем процессе. Для начала необходимо убедиться в том, что локальная ветка master синхронизирована с вышестоящей веткой master. Затем выполняется слияние функциональной ветки с веткой master, и обновленная ветка master отправляется обратно в центральный репозиторий.

Работу с запросами pull можно упростить с помощью решений по управлению репозиториями продуктов, например Bitbucket Cloud или Bitbucket Server. Для примера можно изучить документацию Bitbucket Server по запросам pull.

Пример

Ниже приводится пример сценария, в котором используется рабочий процесс с функциональными ветками. В этом сценарии команда выполняет проверку кода в рамках запроса pull по новой функции. Это один из множества вариантов использования данной модели.

Мэри начинает разработку новой функции

Рабочий процесс с функциональными ветками: коммит изменений

Чтобы начать разработку новой функции, Мэри необходимо иметь обособленную ветку для работы. Она может запросить новую ветку с помощью следующей команды:

git checkout -b marys-feature master

Команда выполняет переключение на ветку с именем marys-feature, основанную на ветке master, а флаг -b предписывает создать ветку в системе Git, если она еще не существует. В этой ветке Мэри без ограничений редактирует, индексирует и подтверждает изменения с помощью коммитов:

 git status git add  git commit

Мэри идет на обед

Рабочий процесс с функциональными ветками: git push

В первой половине дня Мэри добавляет к функции новые коммиты. Перед тем как пойти на обед, она решает отправить функциональную ветку в центральный репозиторий. Это удобный способ создания резервной копии, а кроме того, если бы Мэри работала совместно с другими разработчиками, это дало бы им доступ к ее первоначальным коммитам.

git push -u origin marys-feature

Эта команда отправляет ветку marys-feature в центральный репозиторий (источник), а с помощью флага -u она добавляется в качестве удаленной отслеживаемой ветки. После настройки отслеживаемой ветки Мэри может вызвать для отправки функции команду git push без дополнительных параметров.

Мэри завершает работу над функцией

Рабочий процесс с функциональными ветками: git push

Вернувшись с обеда, Мэри завершает разработку функции. Перед слиянием с веткой master ей необходимо отправить запрос pull, чтобы сообщить остальным участникам команды о готовности работы. Но сначала ей необходимо отправить в центральный репозиторий свои последние коммиты:

git push

Затем Мэри с помощью графического интерфейса Git отправляет запрос pull на слияние ветки marys-feature с веткой master, о чем участники ее команды автоматически получают уведомление. Большим преимуществом запросов pull является то, что в них комментарии отображаются непосредственно рядом со связанными коммитами. Это позволяет с легкостью задавать вопросы о конкретных наборах изменений.

Билл получает запрос pull

Рабочий процесс с функциональными ветками: проверка запроса pull

Билл получает запрос pull и изучает ветку marys-feature. Билл считает, что перед ее интеграцией в официальный проект необходимо внести несколько изменений, и они с Мэри обсуждают это в запросе pull.

Мэри вносит изменения

Рабочий процесс с функциональными ветками: проверка запросов pull

Чтобы внести изменения, Мэри выполняет ту же процедуру, что и при создании первой итерации функции. Она редактирует, индексирует, подтверждает и отправляет обновленные данные в центральный репозиторий. Все выполняемые действия регистрируются в запросе pull, а Билл может попутно вносить комментарии.

При необходимости Билл может осуществить pull ветки marys-feature в свой локальный репозиторий и работать с ней самостоятельно. Его коммиты также будут регистрироваться в запросе pull.

Мэри публикует функцию

Рабочий процесс с функциональными ветками: слияние функциональных веток

Когда Билл готов принять запрос pull, требуется, чтобы кто-то выполнил слияние функциональной ветки со стабильной версией проекта. Это может сделать Билл или Мэри:

git checkout master git pull git pull origin marys-feature git push 

Часто этот процесс заканчивается коммитом слияния. Некоторые разработчики отдают предпочтение такому варианту, поскольку в этот момент происходит символическое объединение новой функции с остальной базой кода. .Однако сторонники линейной истории перед слиянием могут перебазировать функциональную ветку в последний коммит ветки master, в результате чего слияние произойдет в ускоренном темпе.

В некоторых графических интерфейсах процесс принятия запроса pull автоматизирован: все необходимые команды запускаются простым нажатием кнопки «Принять». Если это не ваш случай, наверняка существует хотя бы возможность автоматического закрытия запроса pull при слиянии функциональной ветки с веткой master.

Тем временем Джон выполняет ту же самую процедуру.

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

Резюме


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

  • ориентация на схемы работы с ветками;
  • возможность использования другими рабочими процессами, предназначенными для работы с репозиториями;
  • поддержка совместной работы с участниками команды посредством запросов pull и проверок слияния.

Использование git rebase на этапах проверки и слияния функциональной ветки создает в Git непрерывную историю слияния функций. Модель функционального ветвления — великолепный инструмент для совместной работы в командной среде.

Прочитайте дополнительные сведения о рабочих процессах Git в подробном руководстве по рабочему процессу Gitflow.

Готовы изучить Git?

Попробуйте это интерактивное учебное руководство.

Начните прямо сейчас