Рабочий процесс с функциональными ветками Git
Основная идея рабочего процесса с функциональными ветками заключается в том, что разработка каждой функции должна происходить в отдельной ветке, а не в главной ветке (main). Такое обособление позволяет нескольким разработчикам с легкостью создавать конкретную функцию, не затрагивая основную базу кода. Кроме того, благодаря этому исключены нарушения кода в ветке main, что является важным преимуществом для среды с непрерывной интеграцией.
Разработка функций в изолированной среде позволяет также создавать запросы pull для обсуждения ветки. Благодаря этому другие разработчики могут утвердить функцию до ее интеграции в официальный проект. Кроме того, если в середине проекта работа замедлится, можно создать запрос pull и попросить совета у коллег. В целом запросы pull существенно облегчают комментирование работы в команде.
Составной рабочий процесс Git с функциональными ветками может использоваться другими высокоуровневыми рабочими процессами Git, которые рассматриваются на странице обзора рабочих процессов Git. Рабочий процесс Git с функциональными ветками ориентирован на модель ветвления кода и представляет собой концепцию создания веток и управления ими. Другие рабочие процессы больше ориентированы на работу с репозиторием. Рабочий процесс Git с функциональными ветками можно интегрировать в другие рабочие процессы. В частности рабочий процесс Gitflow и рабочий процесс Git с форками традиционно используют рабочий процесс Git с функциональными ветками в своих моделях ветвления кода.
Как это устроено
В рабочем процессе с функциональными ветками используется центральный репозиторий, а ветка main отражает официальную историю проекта. Вместо создания коммитов напрямую в локальной ветке main, разработчики создают новую ветку каждый раз при начале работы над новой функцией. Функциональные ветки должны иметь описательные имена (например, animated-menu-items или issue-#1061). Каждая ветка должна быть предназначена строго для одной цели. Технически Git не различает ветку main и функциональные ветки, поэтому в рамках функциональных веток разработчики могут редактировать, индексировать файлы и фиксировать их изменения в виде коммитов.
Кроме того, функциональные ветки можно (и нужно) отправлять в центральный репозиторий. Это позволяет работать над функцией совместно с другими разработчиками, не затрагивая официальный код. Поскольку main — это единственная «особая» ветка, хранение нескольких функциональных веток в центральном репозитории не представляет сложностей. Разумеется, это еще и удобный способ резервного копирования локальных коммитов. Ниже приводится пошаговый обзор жизненного цикла функциональной ветки.
Начните с ветки main
Все функциональные ветки создаются на основе актуального кода проекта. Подразумевается, что он обрабатывается и обновляется в ветке main.
git checkout main
git fetch origin
git reset --hard origin/mainСоздайте репозиторий
Эта команда переключает репозиторий на ветку main, получает последние коммиты и сбрасывает локальную копию ветки main, чтобы она соответствовала последней версии.
Создание новой ветки
Используйте отдельную ветку для каждой функции или задачи, над которой вы работаете. После создания ветки переключитесь на нее локально, чтобы все внесенные изменения сохранялись в ней.
git checkout -b new-featureЭта команда выполняет переключение на ветку new-feature, основанную на ветке main. Флаг -b указывает Git на необходимость создания ветки, если она еще не существует.
Обновление, добавление, коммит и отправка изменений
В этой ветке можно выполнять редактирование, индексирование и отправку изменений обычным способом, используя неограниченное количество коммитов для формирования функции. Работайте над этой функцией и делайте необходимые коммиты, как обычно при использовании Git. Завершив работу, отправьте коммиты, чтобы обновить функциональную ветку в Bitbucket.
git status
git add <some-file>
git commitОтправка функциональной ветки в удаленный репозиторий
Желательно отправлять функциональную ветку в центральный репозиторий. Это удобный способ резервного копирования при совместной работе с другими разработчиками: так они получают возможность просматривать коммиты в новой ветке.
git push -u origin new-featureЭта команда отправляет ветку new-feature в центральный репозиторий (origin), и она посредством флага -u добавляется в качестве удаленной отслеживаемой ветки. После настройки отслеживаемой ветки можно вызвать git push без параметров для автоматической отправки ветки new-feature в центральный репозиторий. Для получения отзыва о новой функциональной ветке создайте запрос pull в системе управления репозиториями, например в Bitbucket Cloud или Bitbucket Data Center. Затем можно добавить проверяющих и убедиться, что все работает правильно, прежде чем выполнять слияние.
Исправление функции по отзывам
На этом этапе коллеги комментируют и утверждают отправленные коммиты. Исправьте функцию по их отзывам локально, а затем сделайте коммит и отправьте рекомендованные изменения в Bitbucket. Обновления отобразятся в запросе pull.
Слияние запроса pull
Если другие пользователи вносили изменения в репозиторий, перед слиянием может потребоваться разрешение конфликтов слияния. Если ваш запрос pull подтвержден и не содержит конфликтов, вы можете добавить код в ветку main. Выполните слияние из запроса pull в Bitbucket.
Запросы pull
Использование веток не только изолирует разработку функций, но и позволяет обсуждать изменения с помощью запросов pull. Когда работа над функцией завершена, ее слияние с веткой main происходит не сразу. Сначала разработчик помещает функциональную ветку на центральный сервер и отправляет запрос pull на слияние своих дополнений с веткой main. Это позволяет другим разработчикам проверить изменения до того, как они будут включены в основную базу кода.
Главное преимущество запросов pull — возможность проверки кода, но изначально они были задуманы как способ обсуждения кода. Запрос pull можно использовать для обсуждения конкретной ветки на раннем этапе в процессе разработки. Например, если разработчику требуется помощь с определенной функцией, достаточно отправить запрос pull. Заинтересованные стороны автоматически получат уведомление и смогут просмотреть вопрос разработчика рядом с соответствующими коммитами.
После принятия запроса pull процедура публикации функции во многом совпадает с аналогичной процедурой в централизованном рабочем процессе. Для начала необходимо убедиться, что локальная ветка main синхронизирована с вышестоящей веткой main. Затем выполняется слияние функциональной ветки с веткой main, и обновленная ветка main помещается обратно в центральный репозиторий.
Работу с запросами pull можно упростить с помощью решений для управления исходным кодом, таких как Bitbucket Cloud.
Пример
Ниже приводится пример сценария, в котором используется рабочий процесс с функциональными ветками. В этом сценарии команда выполняет проверку кода в рамках запроса pull по новой функции. Это один из множества вариантов использования данной модели.
Мэри начинает разработку новой функции
Чтобы начать разработку новой функции, Мэри необходимо иметь обособленную ветку для работы. Она может запросить новую ветку с помощью следующей команды:
git checkout -b marys-feature mainЭта команда выполняет переключение на ветку marys-feature, основанную на ветке main. Флаг -b указывает Git на необходимость создания ветки, если она еще не существует. В этой ветке Мэри без ограничений редактирует, индексирует и подтверждает изменения с помощью коммитов:
git status
git add <some-file>
git commitМэри идет на обед
В первой половине дня Мэри добавляет к функции новые коммиты. Перед тем как пойти на обед, она решает отправить функциональную ветку в центральный репозиторий. Это удобный способ создания резервной копии, а кроме того, если бы Мэри работала совместно с другими разработчиками, это дало бы им доступ к ее первоначальным коммитам.
git push -u origin marys-featureЭта команда отправляет ветку marys-feature в центральный репозиторий (origin), и она посредством флага -u добавляется в качестве удаленной отслеживаемой ветки. После настройки отслеживаемой ветки Мэри может вызвать для отправки функции команду git push без параметров.
Мэри завершает работу над функцией
Вернувшись с обеда, Мэри завершает разработку функции. Перед слиянием с веткой main она должна отправить запрос pull, чтобы сообщить остальным участникам команды о готовности работы. Но сначала ей необходимо отправить в центральный репозиторий свои последние коммиты:
git pushЗатем Мэри с помощью графического интерфейса Git отправляет запрос pull на слияние ветки marys-feature с веткой main, о чем участники ее команды автоматически получают уведомление. Большим преимуществом запросов pull является то, что в них комментарии отображаются непосредственно рядом со связанными коммитами. Это позволяет с легкостью задавать вопросы о конкретных наборах изменений.
Билл получает запрос pull
Билл получает запрос pull и изучает ветку marys-feature.. Билл считает, что перед ее интеграцией в официальный проект необходимо внести несколько изменений, и они с Мэри обсуждают это в запросе pull.
Мэри вносит изменения
Чтобы внести изменения, Мэри выполняет ту же процедуру, что и при создании первой итерации функции. Она редактирует, индексирует, подтверждает и отправляет обновленные данные в центральный репозиторий. Все выполняемые действия регистрируются в запросе pull, а Билл может попутно вносить комментарии.
При необходимости Билл может извлечь ветку marys-feature в свой локальный репозиторий и работать с ней самостоятельно. Его коммиты также будут регистрироваться в запросе pull.
Мэри публикует функцию
Когда Билл готов принять запрос pull, требуется, чтобы кто-то выполнил слияние функциональной ветки со стабильной версией проекта. Это может сделать Билл или Мэри:
git checkout main
git pull
git pull origin marys-feature
git pushЧасто этот процесс заканчивается коммитом слияния. Некоторые разработчики отдают предпочтение такому варианту, поскольку в этот момент происходит символическое объединение новой функции с остальной базой кода. Однако сторонники линейной истории перед слиянием могут перебазировать функциональную ветку на последний коммит ветки main, в результате чего произойдет ускоренное слияние.
В некоторых графических интерфейсах процесс принятия запроса pull автоматизирован: все необходимые команды запускаются простым нажатием кнопки «Принять». Если это не ваш случай, наверняка существует хотя бы возможность автоматического закрытия запроса pull при слиянии функциональной ветки с веткой main.
Тем временем Джон выполняет ту же самую процедуру.
Пока Мэри и Билл работают над веткой marys-feature и обсуждают ее в запросе pull, Джон делает то же самое со своей функциональной веткой. Благодаря изоляции функций в отдельных ветках пользователи могут работать автономно и при необходимости легко делиться изменениями с другими разработчиками.
Тема
В этом документе мы рассмотрели рабочий процесс Git с функциональными ветками. Этот процесс помогает структурировать и отслеживать ветки, предназначенные для разработки бизнес-функций. Другие рабочие процессы Git, например Git-flow или рабочий процесс с форками, ориентированы на работу с репозиториями и могут использовать процесс Git с функциональными ветками для управления моделями ветвления данных. В этом документе был рассмотрен общий пример работы с кодом и вымышленный пример реализации рабочего процесса Git с функциональными ветками. Ниже приводится несколько ключевых особенностей рабочего процесса Git с функциональными ветками:
ориентация на схемы работы с ветками;
возможность использования другими рабочими процессами, предназначенными для работы с репозиториями;
поддержка совместной работы с участниками команды посредством запросов pull и проверок слияния.
Использование git rebase на этапах проверки и слияния функциональной ветки создает в Git непрерывную историю слияния функций. Модель функционального ветвления — великолепный инструмент для совместной работы в командной среде.
Получите дополнительные сведения о рабочих процессах Git в подробном руководстве по рабочему процессу Gitflow.