Closing a pull request
You may choose to close a pull request without merging it into the upstream branch. This can be handy if the changes proposed in the branch are no longer needed, or if another solution has been proposed in another branch.
Tip: If you opened a pull request with the wrong base branch, rather than closing it out and opening a new one, you can instead change the base branch. For more information, see «Changing the base branch of a pull request.»
Under your repository name, click
Pull requests.
In the «Pull Requests» list, click the pull request you’d like to close.
At the bottom of the pull request, below the comment box, click Close pull request.
Optionally, delete the branch. This keeps the list of branches in your repository tidy.
Help us make these docs great!
All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.
Delete a closed pull request from GitHub
I accidentally made a wrong pull request and ended up closing the request myself. It’s in a closed state right now but it’s accessible via direct URL and showing on my activity bar.
Is there any way to delete a pull request completely so it’s no longer accessible via URL or shows up on your activity history?
4 Answers 4
There is no way you can delete a pull request yourself — you and the repo owner (and all users with push access to it) can close it, but it will remain in the log. This is part of the philosophy of not denying/hiding what happened during development.
However, if there are critical reasons for deleting it (this is mainly violation of Github Terms of Service), Github support staff will delete it for you.
Как отменить пулреквест на гитхабе?
Таким образом, запрос на перенос закрывается (и игнорируется) без его объединения.
ответ дан 31 авг.
Это очень далеко на странице. Просто прокрутите вниз до конца. — ларср
Совет: кнопка закрытия находится в запросе на вытягивание на цель репо. Вы не найдете его на странице запроса на перенос в исходном репо. — март
Есть ли способ удалить PR не просто закрыть? Спасибо. — f01
требуется небольшое исправление на странице справки github, щелкните исходное репо, для которого вы отправили запрос на перенос. Нажмите на название PR и прокрутите вниз. — Викрамви
Вопрос был в том, как «УДАЛИТЬ» запрос на перенос, а не как его закрыть, — sea26.2
В духе DVCS (как в «Распространенном») вы не отменяете то, что опубликовали:
Запросы на вытягивание — это, по сути, патчи, которые вы отправляете (обычно по электронной почте, здесь через GitHub webapp), и вы также не отмените электронное письмо;)
Но поскольку система запросов на вытягивание GitHub также включает раздел обсуждения, в котором вы могли бы высказать свое беспокойство получателю этих изменений, попросив его / ее игнорировать 29 из 30 ваших коммитов.
- a / у вас есть раздел предварительного просмотра при выполнении запроса на перенос, позволяющий увидеть количество коммитов, которые будут включены в него, и просмотреть их разницу.
- б / желательно перебазировать работу, которую вы хотите опубликовать, как запрос на вытягивание поверх удаленной ветки, которая получит указанную работу. Затем вы можете сделать запрос на перенос, который получатель может безопасно применить в ускоренном режиме.
При этом с января 2011 г. («Обновленные обсуждения запросов на слияние»), и упомянутый в ответ выше, вы можете закрыть пул-реквест в комментариях.
Найдите кнопку «Прокомментировать и закрыть» внизу страницы обсуждения:
ответ дан 23 мая ’17, 13:05
Пометить это как правильное. После дополнительных исследований я нашел ссылку на самом github, в которой говорится, что запросы на вытягивание не могут быть отменены. Хотя я понимаю теоретический аргумент, который вы выдвигаете против даже наличия этой опции, на практике запрос на перенос — это не что иное, как ссылка, добавленная в базу данных. Итак, на самом деле вы должен иметь возможность отменить запрос — мы не говорим здесь об электронной почте, поэтому не следует ожидать, что мы должны следовать тому же шаблону проектирования, что и электронная почта. — меммоны
@Harkonian: Я полностью согласен с вашим аргументом: источник и место назначения находятся на стороне сервера веб-приложений GitHub, поэтому любое действие (например, отмена) должно быть возможным. Но в настоящее время вам нужно будет сделать «запрос на улучшение» в команду GitHub, чтобы запросить эту функцию. — ФонК
Если вы отправили пул-реквест в репозиторий, где у вас нет прав на его закрытие, вы можете удалить ветку, из которой возник пул-реквест. Это отменит запрос на перенос.
Практическое занятие «Процесс Pull request на GitHub»
На предыдущем занятии Используем клиент 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. Можно объединить форкнутый репозиторий (это типичная модель для опен-сорс проектов со многими внешними участниками), но этот сценарий, вероятно, менее распространен для технических писателей, работающих с разработчиками в тех же проектах.