Как изменить название пул реквеста

5 ответов

Лучший ответ

curl --user "your_github_username" 
     --request PATCH 
     --data '{"title":"newtitle","body":"newbody",...}' 
     https://api.github.com/repos/:owner/:repo/pulls/:number

curl --user "jeremyclement" 
     --request PATCH 
     --data '{"title":"allows the control of files and folders permissions."}' 
     https://api.github.com/repos/Gregwar/Cache/pulls/9

Перевод статьи «How to make your first pull request on GitHub».

Что такое форк?

Когда нам нравится чей-то репозиторий и мы хотели бы иметь его в собственном аккаунте на GitHub, мы делаем форк («вилку») этого репозитория, чтобы иметь возможность работать с ним отдельно.

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

Что такое пул-реквест?

Пул-реквесты нужны. Когда мы хотим
принять участие в групповой разработке
проектов с открытым исходным кодом.

Например, пользователь Павел делает
форк репозитория ThanoshanMV (автора статьи,
— прим. перев.) и вносит изменения в свой
экземпляр. После этого Павел отсылает
пул-реквест ThanoshanMV, который может либо
принять его, либо отклонить. По сути это
что-то вроде письма «Не будете ли вы так
любезны, уважаемый ThanoshanMV, внести мои
изменения в свой оригинальный репозиторий?»

Как можно стать контрибьютором
проекта?

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

1. Дизайн. Можно создать макеты
   проекта, чтобы повысить удобство его
   использования, усовершенствовать
   навигацию или меню, создать рисунки
   для лого или футболок, написать
   руководство по стилю проекта.
2. Писательство. Можно написать
   документацию проекта или улучшить уже
   существующую, перевести документацию
   на свой язык, создать новостную рассылку
   для проекта, написать руководства для
   пользователей или заняться формированием
   папки с примерами использования.
3. Организаторские задачи. Можно
   связывать дублирующиеся issues, предлагать
   новые метки для issues, предлагать закрытие
   старых, но еще открытых issues, задавать
   вопросы в новых — чтобы подстегивать
   развитие дискуссии.
4. Помощь другим людям. Можно
   отвечать на вопросы в открытых issues,
   проверять код других разработчиков,
   предлагать помощь в качестве наставника.
5. Написание кода. Можно помогать
   в решении возникших проблем, предлагать
   создание новых фич, а также улучшать
   инструментарий и тестирование.

Давайте создадим наш первый
пул-реквест!

1. Форк репозитория

Чтобы сделать форк репозитория, нужно
нажать кнопку «Fork» в верху страницы.
Таким образом вы создадите экземпляр
всего этого репозитория в своем аккаунте.

2. Клонирование репозитория

Когда репозиторий уже есть в вашем
аккаунте, вы можете клонировать его на
свою машину и в дальнейшем работать с
ним локально.

Чтобы клонировать репозиторий, нажмите
кнопку «clone» и скопируйте ссылку.

Откройте терминал и запустите следующую
команду. С ее помощью репозиторий будет
клонирован на вашу машину.

$ git clone [HTTPS ADDRESS]

Теперь у вас есть копия ветки master
основного онлайн-репозитория проекта.

Переходим в клонированную директорию:

$ cd [NAME OF REPOSITORY]

3. Создание ветки

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

Имя ветки должно быть коротким и
отражать те изменения, которые вы
вносите.

Создадим ветку при помощи команды git
checkout:

$ git checkout -b [Branch Name]

4. Внесение изменений и коммит

Внесите необходимы изменения в проект
и сохраните их. Затем запустите команду
git status: вы увидите внесенные изменения.

Добавьте эти изменения в только что
созданную ветку при помощи команды git
add:

$ git add .

Теперь вы можете сделать коммит этих
изменений при помощи команды git commit:

$ git commit -m "Adding an article to week 02 of articles of the week"

5. Отправка изменений на
GitHub

Чтобы отправить изменения на GitHub
(сделать push), нужно определить имя
удаленного репозитория.

$ git remote

Имя данного удаленного репозитория
— «origin».

После определения имени можно безопасно
отправить изменения на GitHub.

git push origin [Branch Name]

6. Создание пул-реквеста

Перейдите в свой репозиторий на GitHub.
Там есть кнопка «Compare & pull request» —
кликните ее.

Введите необходимые детали относительно того, что именно вы сделали (чтобы поставить ссылку на issues, возмользуйтесь знаком «решетки»). После этого можно нажать кнопку подтверждения внизу.

Поздравляю! Вы создали свой первый пул-реквест. Если его примут, вы получите уведомление по электронной почте.

7. Синхронизация вашего форка
с основной веткой

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

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

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

1. Для начала, проверьте, в какой ветке
вы находитесь.

$ git branch

Вы получите список всех веток, причем
активная будет подсвечена зеленым.

2. Переключитесь в ветку master.

$ git checkout master

3. Добавьте оригинальный репозиторий
в качестве upstream-репозитория.

Чтобы вытащить изменения из оригинального репозитория и перенести их в свою версию, нужно добавить оригинальный git-репозиторий в качестве upstream-репозитория.

$ git remote add upstream [HTTPS]

Здесь [HTTPS] это url, который нужно
скопировать из основного репозитория.

4. Fetch репозитория

Заберите (fetch) все изменения из
оригинального репозитория. Коммиты,
сделанные в оригинальном репозитории,
будут сохранены в локальной ветке под
названием upstream/master.

$ git fetch upstream

5. Слейте изменения

Слейте (merge) изменения из upstream/master с
вашей локальной веткой master. Таким образом
главная ветка вашего форка репозитория
синхронизируется с upstream-репозиторием
без потери ваших локальных изменений.

$ git merge upstream/master

6. Отправьте изменения на GitHub

На этом этапе ваша локальная ветка
синхронизирована с веткой master оригинального
репозитория. Если вы хотите обновить
свой GitHub-репозиторий, нужно отправить
в него изменения.

$ git push origin master

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

$ git remote rm [Remote Name]

8. Удаление ненужной ветки

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

$ git branch -d [Branch Name]

Вы можете удалить и версию этой ветки
на GitHub.

git push origin --delete [Branch Name]

Итоги

GitHub это мощный инструмент для контроля
истории версий. Каждый может стать
контрибьютором проекта с открытым
исходным кодом. Делается это путем
отправки пул-реквестов.

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

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

Edit me

На предыдущем занятии Используем клиент GitHub для десктопа, мы использовали Github Desktop для управления рабочим процессом коммитов, ветвления и слияния. На этом занятии мы будем выполнять аналогичные действия, но с использованием браузерного интерфейса, который предоставляет Github, вместо использования терминала или Github Desktop.

Понимание процесса Pull request является важным для анализа изменений в опен-сорс проекте с несколькими участниками. Использование интерфейса GitHub также удобно, если рецензенты не знакомы с терминалом или Github Desktop.

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

По умолчанию в новом репозитории есть одна ветка с именем «Master». Обычно, когда при внесении изменений или просмотра / редактировании, создается новая ветка и вносятся все изменения в ветку. Затем, по окончании, владелец репо объединяет изменения из новой ветки в «Master» через «pull request».

Для создания изменений в отдельной ветке:

• Со стороны рецензента переходим к тому же репозиторию GitHub, который был создан на предыдущем занятии (можно создать новый репо). Создаем новую ветку, выбрав раскрывающееся меню ветки и введя имя новой ветки, например «sme-review». Затем нажмите клавишу Enter.

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

• Кликаем в область ввода текста, а затем кликаем по иконке карандаша («Edit this file»), чтобы отредактировать файл.

• Вносим изменения в контент и прокручиваем вниз экрана до области Commit changes. Поясняем причину изменений и подтверждаем изменения в своей ветке sme-review, нажав кнопку Commit changes.

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

Создание Pull request

Теперь представим, что процесс проверки завершен, и пришло время объединить ветку с мастером. Ветка объединяется с “Master” через Pull request. Любой «соавтор» в команде с правами на запись может инициировать и завершить Pull request (добавлять соавторов можете в «Настройки»> «Соавторы)

Для создания Pull request:

• Находим на экране вкладку “Pull request”.
• Кликаем по кнопке New pull request

• Выбираем ветку (sme-review), которую хотим сравнить с веткой “Master”

Когда мы сравниваем ветку с мастером, мы увидим список всех изменений. Мы можем просмотреть изменения в двух режимах просмотра: Unified или Split (это вкладки, показанные справа от содержимого). Unified показывает правки вместе в одной области содержимого, тогда как split показывает два файла рядом.

• Кликаем на кнопку Create pull request.
• Поясняем pull request и снова кликаем кнопку Create pull request.

Владелец репозитория увидит pull request и сможет принять меры для его объединения.

Процесс Pull request

Теперь посмотрим на процесс со стороны владельцем проекта, который получил новый Pull request. Владельцу нужно обработать Pull request и объединить ветку sme-review с “Master”.

• Переходим на вкладку “Pull requests”, чтобы увидеть ожидающие запросы на извлечение.
• Кликаем по запросу и смотрим изменения, выбрав вкладку Files changed.

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

• Переходим на вкладку “Conversation” и кликаем кнопку Merge pull request.
• кликаем Confirm merge.

Ветка sme-review объединяется с мастером. Теперь “Master” и ветка sme-review совпадают (ветки “смержены”).

• Кликаем кнопку Delete branch для удаления ветки sme-review.

Не обязательно удалять ветку сразу. Старые ветки всегда можете удалить , щелкнув ссылку на ветки при просмотре репозитория Github, а затем нажмите кнопку Delete (корзина) рядом с веткой.

Если посмотреть на список веток, то после удаления ветка sme-review больше не отображается.

Добавление участников в проект

Иногда необходимо добавлять соавторов в проект Github, чтобы они могли вносить изменения в ветку. Если другие участники проекта, не являясь соавторами, захотят внести изменения, они получат сообщение об ошибке. (Inviting collaborators to a personal repository)

Человек без прав на запись, может “форкнуть” (скопировать) репо, а не вносить изменения в ветку в том же проекте. Однако копирование проекта клонирует весь репозиторий, а не создает ветку в том же репозитории. Форк (копия) будет существовать в учетной записи пользователя GitHub. Можно объединить форкнутый репозиторий (это типичная модель для опен-сорс проектов со многими внешними участниками), но этот сценарий, вероятно, менее распространен для технических писателей, работающих с разработчиками в тех же проектах.

Для добавления соавторов в проект:

• В репозитории проекта переходи на вкладку “Settings”.
• Нажимаем на кнопку Collaborators в левой части.
• Вводим имена пользователей Github тех, кому хотим дать доступ в области Collaborator.
• Нажимаем на кнопку Add collaborator.

🔙

Go next ➡

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

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

1. Ветвление

Ветвление означает, что вы отклоняетесь от основной линии разработки и продолжаете работу, не связываясь с ней.

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

Новая ветка должна быть создана из последнего кода ее восходящей ветки. Иначе говоря, HEAD коммит локальной ветки должен совпадать с HEAD коммитом восходящей. 

Это поможет сделать историю коммитов более ясной в будущем пул-реквесте. Ветвление с помощью команд Git можно сделать следующим образом:

git fetch --all #1

git checkout upstream/dev #2

git checkout -b Feature/New #3

• #1 Запросить последнюю версию кода из вашего удаленного репозитория. 
• #2 Переключиться на последний код восходящей ветки разработки.
• #3 Создать новую ветку под именем Feature/New, используя последний код ветки разработки.

Вы также можете применить указанный способ для получения того же результата, используя SourceTree. Что касается стандартных имен ветвей, то в большинстве случаев можно найти master, release или development. А какие имена лучше подойдут для ветвей, посвященных рефакторингу, добавлению новых элементов или исправлению багов? Я бы предложил два варианта имени.

На основе номера тикета или проблемы

Предположим, что вы работаете над Jira тикетом VAJ-96 об устранении бага на главном экране. В этом случае вы можете назвать ветку так:

VAJ-96/Fix_Bug_In_Home_Screen

Этот принцип подойдет и для тикетов, требующих создания нескольких веток: 

VAJ-96/Fix_Bug_1_In_Home_Screen

VAJ-96/Fix_Bug_2_In_Home_Screen

VAJ-96/Fix_Bug_3_In_Home_Screen

Имена по типу ветки

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

Feature/Pet_Dating

Feature/Music_For_Pet#or

Fix/Loading_Issue

Fix/Crash_In_Home_Screen#or

Refactor/Duplicated_Code

Refactor/Module_A

Если вы пользуетесь терминалом, то одним из преимуществ станет функция автодополнения. В случае с SourceTree она выглядит так:

2. Коммит

Крутой пул-реквест должен иметь крутой список коммитов. Что ж, разберёмся с коммитами.

Содержимое коммита

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

Не оттягивайте с коммитом до полного завершения, но и не стоит частить, делая коммит после каждой строчки кода, главное  —  делать его вовремя.

Имя коммита

Доводилось ли вам видеть коммиты: “это коммит”, “что исправить” или “я не знаю, что я делаю”? Звучит смешно, но встречается каждый день. Честно говоря, иногда вы или ваши коллеги можете ужаснуться, когда нужно найти что-то из предыдущих версий. Поэтому имя коммита должно передавать конкретные изменения и выглядеть, например, так:

Fix: - Fixed the crash in Home Screen.

Feature: - Implemented GameView in Play Screen.

Merge: - Merged latest develop to the feature branch.

Chore: - Increased the build number to 68 on Production.

Refactor: - Replaced Singleton pattern by Dependencies Injection.

Старайтесь делать сообщение коротким, но ясным. 

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

Я советую поставить себя на место просматривающего код человека в будущем и в самом конце еще раз посмотреть на код перед созданием пул-реквеста (шаг 3). Если вы сочтете, что в нем есть потенциальные улучшения, то обязательно улучшайте. Пусть код выглядит наилучшим образом. В будущем это сохранит много времени вам и вашим коллегам.

3. Предложение пул-реквеста

Хороший пул-реквест должен иметь четкое имя, сопровождающееся детальным описанием, и дополнительными тегами или аннотациями.

Имя

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

Описание

Описание помогает лучше понять, зачем что-то написали в коде, его достоинства и ознакомиться с пояснениями его создателя. Иначе говоря, оно должно отвечать на три вопроса: 

• Зачем? Над какими тикетами, проблемами или предложениями вы работаете?
• Что? Что именно вы сделали?
• Как? Что нужно знать тем, кто смотрит ваш код?

Теги и аннотации

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

4. Обзор

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

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

С другой стороны, будучи обозревателем кода, лучше сосредотачиваться именно на коде, а не на человеке.

Не тратьте много времени на споры и не переходите на личности. В конце концов, все мы одна команда, которая старается сделать мир лучше.

5. Одобрение и слияние

Разрешив все вопросы о внесении изменений и получив одобрение, вы можете сливать ваши пул-реквесты с удаленной веткой. Для этого существует множество способов. Я использую два основных: добавление коммита на слияние поверх всех остальных коммитов пул-реквеста или сжатие всех коммитов в один на слияние.

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

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

Слияние завершено? Вы сами решаете, что делать с созданной вами моделью ветвления. Вы можете либо стереть ее, либо сохранить для дальнейшей работы. 

Поздравляю с завершением задачи! Сделайте небольшой перерыв и приступайте к следующей. 

Благодарю вас за внимание!

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

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

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

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

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

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

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

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

Пул-реквесты можно применять в сочетании с процессами Feature Branch Workflow, Gitflow Workflow или Forking Workflow. При этом для использования пул-реквестов требуются две отдельные ветки или два отдельных репозитория. Поэтому пул-реквесты не будут работать при использовании процесса Centralized Workflow. Использование пул-реквестов в каждом из перечисленных процессов имеет свои нюансы, но общий подход описан ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"

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

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

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

git push origin some-branch

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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