Тянуть запросы | Atlassian Git Tutorial

1. Анатомия запроса тяги
2. Как это устроено
3. Рабочий процесс ветки компонента с запросами на извлечение
4. Рабочий процесс Gitflow с запросами Pull
5. Форкинг рабочего процесса с запросами на извлечение
6. пример
7. Мэри разветвляется официальный проект
8. Мэри клонирует свой репозиторий Bitbucket
9. Мэри разрабатывает новую функцию
10. Мэри добавляет эту функцию в свой репозиторий Bitbucket.
11. Мэри создает запрос на извлечение
12. Джон рассматривает запрос на извлечение
13. Мэри добавляет последующий коммит
14. Джон принимает запрос на извлечение
15. Куда пойти отсюда

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

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

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

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

Анатомия запроса тяги

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

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

Как это устроено

Запросы на извлечение можно использовать вместе с Рабочий процесс ветки , Gitflow Workflow , или Форкинг рабочего процесса , Но для запроса на вытягивание требуются либо две разные ветви, либо два разных репозитория, поэтому они не будут работать с Централизованный рабочий процесс , Использование запросов на получение с каждым из этих рабочих процессов немного отличается, но общий процесс выглядит следующим образом:

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

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

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

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

5. Сопровождающий проекта объединяет эту функцию с официальным репозиторием и закрывает запрос на извлечение.

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

Рабочий процесс ветки компонента с запросами на извлечение

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

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

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

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

Рабочий процесс Gitflow с запросами Pull

Рабочий процесс Gitflow похож на рабочий процесс Feature Branch, но определяет строгую модель ветвления, разработанную для выпуска проекта. Добавление запросов на извлечение в Gitflow Workflow дает разработчикам удобное место для обсуждения ветки релиза или ветки обслуживания, пока они над этим работают.

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

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

Форкинг рабочего процесса с запросами на извлечение

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

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

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

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

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

пример

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

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

Мэри разветвляется официальный проект

Чтобы начать работать над проектом, Мэри сначала нужно разветвить репозиторий Джона Битбакета. Она может сделать это, войдя в Bitbucket, перейдя в репозиторий Джона и нажав кнопку Fork .

После заполнения имени и описания для разветвленного репозитория у нее будет копия проекта на стороне сервера.

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

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

git clone https: //[email protected]/user/repo.git

Имейте в виду, что git clone автоматически создает удаленный источник, который указывает на разветвленный репозиторий Мэри.

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

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

git checkout -b some-feature # Редактировать некоторый код git commit -a -m "Добавить первый черновик некоторой функции"

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

Мэри добавляет эту функцию в свой репозиторий Bitbucket.

После того, как ее функция завершена, Мэри отправляет ветку функций в свой собственный репозиторий Bitbucket (не официальный репозиторий) простым нажатием git:

git push origin some-branch

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

Мэри создает запрос на извлечение

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

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

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

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

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

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

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

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

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

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

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

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

Куда пойти отсюда

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

Похожие

Комментарии