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

Рабочие процессы Git: запрос pull в Bitbucket

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

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

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

По сравнению с другими моделями совместной работы это формальное решение для обмена коммитами обеспечивает гораздо более упорядоченный рабочий процесс. SVN и Git могут автоматически отправлять уведомления по электронной почте с помощью простого скрипта; однако когда дело доходит до обсуждения изменений, разработчикам обычно приходится вести диалог по электронной почте. Такой подход может внести путаницу, особенно если начинается обмен дополняющими коммитами. Запросы pull помещают все эти функции в удобный веб-интерфейс рядом с репозиториями Bitbucket.

Структура запроса pull

Создавая запрос pull, вы просите другого разработчика (например, человека, занимающегося поддержкой проекта) осуществить pull ветки из вашего репозитория в его репозиторий. Поэтому для создания запроса pull необходимо указать четыре параметра: исходный репозиторий, исходную ветку, репозиторий назначения и ветку назначения.

Рабочие процессы Git: запросы pull

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

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

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

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

  2. Разработчик помещает эту ветку в публичный репозиторий Bitbucket.

  3. Разработчик создает запрос pull через Bitbucket.

  4. Остальные участники команды проверяют код, обсуждают его и вносят изменения.

  5. Человек, занимающийся поддержкой проекта, сливает функцию в официальный репозиторий и закрывает запрос pull.

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

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

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

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

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

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

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

Использование запросов pull в рабочем процессе Gitflow

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

Запросы pull: рабочий процесс Gitflow Workflow Запросы pull: рабочий процесс Gitflow Workflow 2

Механизм запросов pull в рабочем процессе Gitflow аналогичен описанному выше: разработчик просто создает запрос pull, когда необходимо проверить функцию, релиз или ветку исправлений, а остальные участники команды получают уведомления через Bitbucket.

Слияние функциональных веток обычно выполняют в ветку develop, а слияние веток релизов и исправлений выполняют и в ветку develop, и в ветку master. Запросы pull можно использовать в качестве инструмента формального управления всеми этими слияниями.

Использование запросов pull в рабочем процессе с форками

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

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

Запросы pull: рабочий процесс с форками

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

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

Запросы pull: рабочий процесс с форками

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

Пример

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

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

Мэри создает форк официального проекта

Запросы pull: создание форка проекта

Чтобы начать работу над проектом, Мэри сначала должна создать форк репозитория Джона в Bitbucket. Для этого ей нужно войти в Bitbucket, перейти к репозиторию Джона и нажать кнопку Fork (Создать форк).

Запрос pull: создание форка в Bitbucket

Указав имя и описание для репозитория, создаваемого с помощью форка, она получит копию серверной части проекта.

Мэри клонирует свой репозиторий Bitbucket

Запрос pull: клонирование репозитория Bitbucket

Затем Мэри должна клонировать репозиторий Bitbucket, который она только что создала с помощью форка. Так она получит собственную рабочую копию проекта на своей локальной машине. Она может сделать это с помощью следующей команды:

git clone https://user@bitbucket.org/user/repo.git

Помните, что команда git clone автоматически создает удаленный репозиторий origin, который указывает на репозиторий Мэри, созданный с помощью форка.

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

Запросы pull: разработка новой функции

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

git checkout -b some-feature
# Изменение кода
git commit -a -m "Add first draft of some feature"

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

Мэри помещает функциональную ветку в свой репозиторий Bitbucket

Запросы pull: помещение функции в репозиторий Bitbucket

Закончив работу, Мэри помещает функциональную ветку в свой репозиторий Bitbucket (а не в официальный репозиторий проекта) с помощью простой команды git push:

git push origin some-branch

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

Мэри создает запрос pull

Запрос pull: создание запроса pull

После добавления функциональной ветки в Bitbucket Мэри из своего аккаунта Bitbucket может создать запрос pull. Для этого ей нужно перейти в свой репозиторий, созданный с помощью форка, и нажать кнопку Pull request (Запрос pull) в верхнем правом углу. Отобразится форма, в которой репозиторий Мэри автоматически будет указан в качестве исходного. Мэри останется указать исходную ветку, а также репозиторий и ветку назначения.

Мэри хочет выполнить слияние функциональной ветки с основной базой кода, поэтому исходная ветка — ее функциональная ветка, репозиторий назначения — публичный репозиторий Джона, а ветка назначения — master. Мэри потребуется ввести заголовок и описание запроса pull. Если код Мэри должен одобрить кто-то помимо Джона, таких участников можно указать в поле Reviewers (Проверяющие).

Запрос pull: Bitbucket

После создания запроса pull Джону будет отправлено уведомление через Bitbucket и (опционально) по электронной почте.

Джон просматривает запрос pull

Запрос pull: запросы pull Bitbucket

Джон может увидеть все созданные другими разработчиками запросы pull, перейдя на вкладку Pull request (Запрос pull) в своем репозитории Bitbucket. Нажав на запрос pull Мэри, он увидит его описание, историю коммитов функциональной ветки и все изменения в запросе pull.

Если Джон считает функцию готовой к слиянию, ему достаточно нажать кнопку Merge (Слить), чтобы одобрить запрос pull и выполнить слияние функциональной ветки Мэри со своей веткой master.

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

Запрос pull: комментарии

Мэри добавляет дополняющий коммит

Если у Мэри есть какие-либо вопросы по поводу отзыва Джона, она может ответить внутри запроса pull, используя его как форум для обсуждения функции.

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

Джон принимает запрос pull

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

Куда можно перейти отсюда

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

Готовы попробовать создать запрос pull?

Ознакомьтесь с этим интерактивным обучающим руководством.

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