The GitHub Blog
Introducing draft pull requests
At GitHub, we’ve always felt that you should be able to open a pull request to start a conversation with your collaborators as soon as your brilliant idea or code is ready to take shape. Even if you end up closing the pull request for something else, or refactoring the code entirely, a good pull request is as much about collaboration as it is about code.
But what if you want to signal that a pull request is just the start of the conversation and your code isn’t in any state to be judged? Perhaps the code is for a hackathon project. You have no intention of ever merging it, but you’d still like people to check it out locally and give you feedback. Or perhaps you’ve opened a pull request without any code at all in order to get the discussion started.
Tag your work in progress
With draft pull requests, you can clearly tag when you’re coding a work in progress. Now when you open a pull request, a dropdown arrow appears next to the “Create pull request” button. Toggle the dropdown arrow whenever you want to create a draft instead.
A draft pull request is styled differently to clearly indicate that it’s in a draft state. Merging is blocked in draft pull requests. Change the status to “Ready for review” near the bottom of your pull request to remove the draft state and allow merging according to your project’s settings. Also, if you have a CODEOWNERS file in your repository, a draft pull request will suppress notifications to those reviewers until it is marked as ready for review.
Get started
Draft pull requests are ready for your code in public and open source repositories, as well as in private repositories for groups using GitHub Team and Enterprise Cloud.
About pull requests
In this article
Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.
About pull requests
Note: When working with pull requests, keep the following in mind:
You can create pull requests on GitHub.com, with GitHub Desktop, in Codespaces, on GitHub for mobile, and when using GitHub CLI.
After initializing a pull request, you’ll see a review page that shows a high-level overview of the changes between your branch (the compare branch) and the repository’s base branch. You can add a summary of the proposed changes, review the changes made by commits, add labels, milestones, and assignees, and @mention individual contributors or teams. For more information, see «Creating a pull request.»
Once you’ve created a pull request, you can push commits from your topic branch to add them to your existing pull request. These commits will appear in chronological order within your pull request and the changes will be visible in the «Files changed» tab.
Other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request.
You can see information about the branch’s current deployment status and past deployment activity on the «Conversation» tab. For more information, see «Viewing deployment activity for a repository.»
After you’re happy with the proposed changes, you can merge the pull request. If you’re working in a shared repository model, you create a pull request and you, or someone else, will merge your changes from your feature branch into the base branch you specify in your pull request. For more information, see «Merging a pull request.»
If status checks are required for a repository, the required status checks must pass before you can merge your branch into the protected branch. For more information, see «About protected branches.»
You can link a pull request to an issue to show that a fix is in progress and to automatically close the issue when someone merges the pull request. For more information, see «Linking a pull request to an issue.»
Tips:
You can visit your dashboard to quickly find links to recently updated pull requests you’re working on or subscribed to. For more information, see «About your personal dashboard.»
Draft pull requests
Draft pull requests are available in public repositories with GitHub Free for organizations and legacy per-repository billing plans, and in public and private repositories with GitHub Team, GitHub Enterprise Server 2.17+, and GitHub Enterprise Cloud. For more information, see «GitHub’s products.»
When you create a pull request, you can choose to create a pull request that is ready for review or a draft pull request. Draft pull requests cannot be merged, and code owners are not automatically requested to review draft pull requests. For more information about creating a draft pull request, see «Creating a pull request» and «Creating a pull request from a fork.»
When you’re ready to get feedback on your pull request, you can mark your draft pull request as ready for review. Marking a pull request as ready for review will request reviews from any code owners. You can convert a pull request to a draft at any time. For more information, see «Changing the stage of a pull request.»
Differences between commits on compare and pull request pages
The compare and pull request pages use different methods to calculate the diff for changed files:
Выполнение запроса pull
Пул-реквесты облегчают совместную работу разработчиков в 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. Использование пул-реквестов в каждом из перечисленных процессов имеет свои нюансы, но общий подход описан ниже.
Разработчик создает функцию в отдельной ветке в своем локальном репозитории.
Разработчик отправляет эту ветку в публичный репозиторий Bitbucket командой push.
Разработчик создает запрос pull через Bitbucket.
Остальные участники команды проверяют код, обсуждают его и вносят изменения.
Человек, занимающийся поддержкой проекта, сливает функцию в официальный репозиторий и закрывает запрос 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.
Использование запросов pull в рабочем процессе с форками
В процессе с использованием форков разработчик помещает завершенную функциональную ветку в собственный публичный репозиторий, а не в общий репозиторий. После этого разработчик создает пул-реквест, оповещая человека, занимающегося поддержкой проекта, о готовности кода к проверке.
Для этого рабочего процесса наличие уведомления в запросе pull особенно важно, иначе человек, занимающийся поддержкой проекта, не сможет узнать о том, что другой разработчик добавил коммиты в свой репозиторий Bitbucket.
Кроме того, пул-реквесты можно использовать для совместной работы с другими разработчиками за пределами официального репозитория проекта. Например, если разработчик работал над функциональной веткой вместе с коллегой, они могут создать пул-реквест, указав в качестве назначения репозиторий Bitbucket коллеги, а не официальный репозиторий проекта. Тогда они смогут указать в качестве исходной ветки и ветки назначения одну и ту же функциональную ветку.
Два разработчика могут обсуждать и разрабатывать функцию внутри запроса pull. По окончании разработки один из них создает новый запрос pull на слияние этой функции с официальной главной веткой. Такая гибкость делает запросы pull невероятно мощным инструментом совместной работы в рамках рабочего процесса с форками.
Пример
В приведенном ниже примере демонстрируется использование запросов pull в рабочем процессе с форками. Он одинаково применим как для разработчиков, работающих в маленьких командах, так и для независимых разработчиков, участвующих в проекте с открытым исходным кодом.
В данном примере Мэри — разработчик, а Джон — человек, занимающийся поддержкой проекта. У обоих есть собственные публичные репозитории Bitbucket, и в репозитории Джона находится официальный проект.
Мэри создает форк официального проекта
Чтобы начать работу над проектом, Мэри сначала должна создать форк репозитория Джона в Bitbucket. Для этого ей нужно войти в Bitbucket, перейти к репозиторию Джона и нажать кнопку Fork.
Указав имя и описание для репозитория, создаваемого с помощью форка, она получит копию серверной части проекта.
Мэри клонирует свой репозиторий Bitbucket
Затем Мэри должна клонировать репозиторий Bitbucket, который она только что создала с помощью форка. Так она получит собственную рабочую копию проекта на своей локальной машине. Она может сделать это с помощью следующей команды:
Мэри разрабатывает новый функционал
Прежде чем писать какой бы то ни было код, Мэри должна создать новую ветку для функции. Эту ветку она будет использовать в качестве исходной в запросе pull.
Мэри может выполнять сколько угодно коммитов во время работы над функциональной веткой. Если история создания функциональной ветки выглядит слишком запутанной, она может использовать интерактивную операцию rebase для удаления или склеивания ненужных коммитов. Такая очистка истории функциональной ветки в больших проектах помогает человеку, занимающемуся поддержкой проекта, быстрее понять, что включено в пул-реквест.
Мэри помещает функциональную ветку в свой репозиторий Bitbucket
Закончив свою задачу, Мэри помещает функциональную ветку в собственный репозиторий Bitbucket (не в официальный репозиторий проекта) с помощью простой команды git push :
Так изменения Мэри будут доступны человеку, занимающемуся поддержкой проекта (или любым другим участникам, которым может понадобиться доступ к этим изменениям).
Мэри создает запрос pull
После добавления своей функциональной ветки в Bitbucket Мэри из своего аккаунта Bitbucket может создать пул-реквест, перейдя в свой репозиторий, созданный с помощью форка, и нажав на кнопку Pull request в верхнем правом углу. Отобразится форма, в которой репозиторий Мэри автоматически будет указан в качестве исходного. Мэри останется указать исходную ветку, а также репозиторий и ветку назначения.
После создания запроса pull Джону будет отправлено уведомление через Bitbucket и (опционально) по электронной почте.
Джон просматривает запрос pull
Джон может увидеть все созданные другими разработчиками пул-реквесты, перейдя на вкладку Pull request в своем репозитории Bitbucket. Нажав на пул-реквест Мэри, он увидит описание пул-реквеста, историю коммитов функциональной ветки и все изменения в пул-реквесте.
Но для примера представим, что Джон нашел небольшой баг в коде Мэри и хочет, чтобы он был исправлен перед слиянием. Джон может либо опубликовать комментарий к запросу pull в целом, либо выбрать определенный коммит в истории функциональной ветки и прокомментировать его.
Мэри добавляет дополняющий коммит
Если у Мэри есть какие-либо вопросы по поводу отзыва Джона, она может ответить внутри запроса pull, используя его как форум для обсуждения функции.
Для исправления ошибки Мэри добавляет другой коммит в свою функциональную ветку и помещает этот коммит в свой репозиторий Bitbucket, как и в первый раз. Коммит автоматически добавится в исходный запрос pull, и Джон сможет снова просмотреть изменения прямо рядом с его исходным комментарием.
Джон принимает запрос pull
Куда можно перейти отсюда
Теперь у вас есть все необходимые инструменты, чтобы начать использование пул-реквестов в текущем рабочем процессе. Помните, что пул-реквесты не заменяют процессы совместной работы в Git, а лишь дополняют их, облегчая взаимодействие всех членов команды.
Готовы попробовать создать запрос pull?
Ознакомьтесь с этим интерактивным обучающим руководством.
Что такое pull request?
Что такое «пул реквест» (pull request), который на GitHub, и как его применить?
4 ответа 4
К вышесказанному можно добавить следующее. Далеко не все пулл-реквесты принимаются разработчиками. Тут нужно соблюсти ряд правил:
Пулл-реквест (ПР) должен быть хорошо оформлен и содержать исчерпывающее описание.
Очень важно соблюдать Code Style того проекта, для которого вы делаете ПР. Пусть даже он кажется вам противоестественным (например вы всегда делаете отступы в виде 4 пробелов, а в проекте табы).
Не нужно бояться делать ПР-ы, ведь помочь можно даже в мелочи. Например вы заметили ошибку перевода в readme файле или вам кажется что какое-то описание фичи можно более понятно перефразировать.
На гитхабе миллионы проектов, живущие исключительно на энтузиазме создателей, хорошие ПР-ы очень хорошо подстегивают этот энтузиазм)
еще добавки к вышесказанному: возможный (я им пользуюсь) механизм работы с репами/pr:
git clone https://github.com/ваш_юзернейм/sqlpp11.git
git remote add upstream https://github.com/rbock/sqlpp11.git (т.е. мы добавляем псевдоним upstream для оригинального репозитория, мы не можем добавлять в него изменения, но можем их получать)
теперь вы правите файлы в вашем origin, в вашей ветке, пушите их в свой форк гитхаба (origin), откуда и делаете pull-request
при этом вы можете сделать git merge/pull/fetch upstream с оригинального репозитория (upstream)
если в upstream настроена интеграция типа travis-ci (как в моем примере), лучше не делать пулл-реквесты, пока не настроите travis-ci для своего репозитория и ваши билды не будут работать правильно (чтобы не мучать мэйнтейнера upstream бессмысленными сообщениями о неудачных сборках в пулл-реквесте)
1. Что такое pull request?
1. Определение
pull request — предложение изменения кода в чужом репозитории.
Вы делаете форк чужого репозитория (который иногда и сам может быть форком) → производите изменения в своём форке → посредством pull request предлагаете изменения владельцам репозитория, чей форк Вы сделали. На GitHub pull request в публичный репозиторий может осуществить любая/ой зарегистрированная/ый участница/участник.
2. Составляющие pull requests
Рекомендации по грамотному внесению pull requests расписаны в ответе ув-мого IonDen.
3. Разновидности pull requests
Все pull requests можно разделить на следующие категории:
4. Дополнительная ссылка
2. Как сделать и принять pull request при помощи hub
1. Что такое hub?
hub — консольное приложение, упрощающее введение команд git, обёртка для git. Например, чтобы клонировать репозиторий, используя git, мы должны ввести в терминал:
В hub команда выглядит проще:
Полный список команд hub, и что они упрощают, см. в документации hub.
2. Зачем использовать hub?
Фиксить мелкие баги и опечатки, а затем сделать pull-request проще через веб-интерфейс GitHub. Однако если Ваши изменения довольно значительны, лучше клонировать репозиторий к себе на компьютер по следующим причинам:
Итак, вы решили клонировать репозиторий. hub упрощает:
3. Настройка hub перед использованием
Если путь к исполняемому файлу содержит пробелы, во избежание багов, лучше заключить его в кавычки.
При необходимости резервных копий или синхронизации пользовательской конфигурации файлов git узнать, где хранятся конфигурационные файлы git, начиная с версии 2.8 можно командой:
Например, у меня в Windows 10 путь к файлу, где хранится данная настройка для комментариев, оказался следующим:
Если Ваша проблема отлична от расписанных здесь, и её разрешения не получается найти поисками Google и по репозиторию; попробуйте ещё раз воспроизвести проблему, перед введением команд hub послав в терминал следующую команду:
В терминале появится отладочная информация. Если и по ней не получилось разрешить проблему, создайте багрепорт в issue tracker hub, приложив к сообщению вывод Вашего терминала вместе с отладочной информацией.
4. Пример создания pull request через hub
Сделаем посредством PowerShell и hub pull request в репозиторий https://github.com/LightAlf/bioRepo1. Помимо вышеперечисленных команд hub в примере используются также команды git, о предназначении которых можно узнать, например, из данного или этого ресурсов на русском.
5. Пример принятия pull-request при помощи hub
В описании коммита по умолчанию будут ссылки на коммит, которым приниматеся pull request, и на сам pull request, а также его заголовок.
Пользовательница/пользователь GitHub, у которой/которого Вы приняли pull request, не сразу, но будет указана/указан в числе контрибьюторов Вашего репозитория.
Changing the stage of a pull request
In this article
You can mark a draft pull request as ready for review or convert a pull request to a draft.
People with write permissions to a repository and pull request authors can change the stage of a pull request.
Draft pull requests are available in public repositories with GitHub Free for organizations and legacy per-repository billing plans, and in public and private repositories with GitHub Team, GitHub Enterprise Server 2.17+, and GitHub Enterprise Cloud. For more information, see «GitHub’s products.»
Marking a pull request as ready for review
When you’re ready to get feedback on your pull request, you can mark your draft pull request as ready for review. Marking a pull request as ready for review will request reviews from any code owners.
Tip: You can also mark a pull request as ready for review using the GitHub CLI. For more information, see » gh pr ready » in the GitHub CLI documentation.
Under your repository name, click
Pull requests.
In the «Pull requests» list, click the pull request you’d like to mark as ready for review.
Converting a pull request to a draft
You can convert a pull request to a draft at any time. For example, if you accidentally opened a pull request instead of a draft, or if you’ve received feedback on your pull request that needs to be addressed, you can convert the pull request to a draft to indicate further changes are needed. No one can merge the pull request until you mark the pull request as ready for review again. People who are already subscribed to notifications for the pull request will not be unsubscribed when you convert the pull request to a draft.
Under your repository name, click
Pull requests.
In the «Pull requests» list, click the pull request you’d like to convert to a draft.
In the right sidebar, under «Reviewers,» click Convert to draft. 
Click Convert to draft. 
