Как удалить pull request github
Перейти к содержимому

Как удалить pull request github

  • автор:

Практическое занятие «Процесс Pull request на GitHub»

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

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

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

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

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

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

new branch

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

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

make edits

  • Кликаем в область ввода текста, а затем кликаем по иконке карандаша («Edit this file»), чтобы отредактировать файл.
  • Вносим изменения в контент и прокручиваем вниз экрана до области Commit changes. Поясняем причину изменений и подтверждаем изменения в своей ветке sme-review, нажав кнопку Commit changes .

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

Создание Pull request

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

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

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

New pull request

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

compare

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

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

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

Процесс Pull request

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

Files changed

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

Note: Для реализации выборочных изменений, переходим в ветку sme-review и вносим обновления перед обработкой pull request. Pull request не дает построчную информацию о том, какие изменения мы хотим принять или отклонить (например, в Microsoft Word «Отслеживать изменения»). Слияние запросов — это процесс «все или ничего». Можно нажать кнопку Review changes , добавить несколько комментариев, а затем установить переключатель «Request changes», попросив рецензента внести изменения.

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

  • Переходим на вкладку “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 .

Как удалить закрытый pull request?

Здравствуйте, есть ли возможность удалить закрытый pull request в своем репозитории?

  • Вопрос задан более года назад
  • 828 просмотров

Комментировать

Решения вопроса 1

sergey-kuznetsov

Сергей Кузнецов @sergey-kuznetsov Куратор тега Git

Автоматизатор

Pull Request в GitHub-репозитории можно только закрыть. Удалить созданный ранее PR невозможно.

Ответ написан более года назад

samodurOFF

Данил Самодуров @samodurOFF Автор вопроса

Что-то GitHub мне нравится все меньше и меньше.

vladgba

Данил Самодуров, а для чего удалять, он же не мешает? Это же система контроля версий, а не твиттер

sergey-kuznetsov

Сергей Кузнецов @sergey-kuznetsov Куратор тега Git

Данил Самодуров, если я вам скажу, что в самом Git тоже невозможно ничего удалить? )) Коммиты по своей природе неизменяемые. Но почему вы это называете минусом системы? Хорошо же когда ничего не теряется и всегда можно откатиться назад.

Ответы на вопрос 0

Ваш ответ на вопрос

Войдите, чтобы написать ответ

git

  • Git

Можно ли сделать git merge, чтобы в главной ветке появился только коммит слияния?

  • 1 подписчик
  • 26 февр.
  • 123 просмотра

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?

9,832 10 10 gold badges 67 67 silver badges 84 84 bronze badges
asked Aug 19, 2013 at 15:56
8,871 9 9 gold badges 56 56 silver badges 81 81 bronze badges
No. You can only close it.
Aug 19, 2013 at 16:14

GitHub account and UI related questions are better for WebApps.StackExchange.com or directly to their support

Aug 26, 2013 at 0:41

You can get rid off all pull requests (and other things like LFS files) by deleting and recreating the repository. Most of the time you cannot afford this but it can help if you mess up early on.

Jan 11, 2017 at 20:16
Great Q and another victim of the SO mandarins. Great answers too.
Mar 4, 2020 at 22:04

6 Answers 6

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.

Whether or not they are willing to delete your PR for you is something you can easily ask them, just drop them an email at [email protected]

Как закрыть пул-реквест на GitHub

Когда вы мерджите пул-реквест на GitHub, у вас есть три опции: merge commit, squash или rebase.

Можно ли просто всегда делать merge commit? Конечно можно! Но применение других стратегий может принести вам некоторые преимущества.

От редакции Techrocks. О том, что такое пул-реквест, можно почитать в статье «Что такое пул-реквесты и зачем они нужны?». О том, как сделать пул-реквест на GitHub, — в статье «Как сделать первый пул-реквест на GitHub».

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

Закрываем пул-реквест на GitHub при помощи squash merge

Вопрос в том, действительно ли вам нужно отслеживать каждый отдельный коммит? Включая исправление опечаток, добавление пропущенных файлов, форматирование… Если нет, то вам стоит рассмотреть вариант squash merge.

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

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

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

Закрываем пул-реквест на GitHub при помощи rebase

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

От редакции Techrocks. О том, что такое rebase, можно почитать в статье «Простое объяснение Git Rebase».

Merge commit дает вам все запутанные линии плюс дополнительный коммит, squash — прямую линию, но с потерей истории. А вот rebase и историю сохраняет, и линию оставляет прямой, и не требует дополнительного коммита для слияния.

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

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

От редакции Techrocks. О конфликтах слияния читайте в статье «Как разрешить конфликт слияния».

Мои пять копеек

На мой взгляд, если ветки не остаются открытыми в течение длительного времени, то squash merge — хороший вариант. Я не являюсь поклонником rebase, потому что слишком легко сделать огромные ошибки. Но прежде чем выбрать стратегию, нужно обдумать несколько моментов.

Например, как часто вам и вашей команде приходится возвращаться к старым коммитам? Сколько членов в команде? Нужна ли вашему CI полная история коммитов?

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

Настройки GitHub

Если вы хотите применять на GitHub только определенные стратегии слияния, зайдите в настройки вашего репозитория и прокрутите страницу немного вниз.

Здесь вы найдете три раздела, позволяющие разрешить merge commit, squash или rebase в ваших пул-реквестах.

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

Для первых двух вариантов вы также можете определить сообщение коммита по умолчанию. Оно может браться из пул-реквеста или из коммитов в ветке в случае squash.

Как видите, rebase не имеет этой опции, и причина проста. Rebase не создаёт дополнительный коммит для слияния, поэтому здесь ничего не нужно делать. Существующие коммиты просто перемещаются к head вашей ветки.

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

Спасибо, что прочитали эту статью, надеюсь, она показалась вам интересной!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *