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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как избавиться от «Merged pull request» коммитов на гитхабе?

На гитхабе если нажать кнопку Merge , то в истории появляется коммит человека, который сделал PR (со временем когда он сделал) и новый твой коммит «Merged PR #123. » с текущим временем. Можно ли избавиться от последнего коммита? Или скрыть его из истории гитхаба? Они захламляют историю, и даты PR и его мержа могут сильно разниться, что ещё больше сбивает с толку.

Отслеживать
задан 3 фев 2023 в 4:45
11 2 2 бронзовых знака

Если во вливаемой ветке мало изменений (например только один коммит), то можно поставить галочку squash, и история будет выглядеть так, будто тот человек сделал свой коммит только что на вершине вашей основной ветки (master/main)

3 фев 2023 в 5:32

@ГерманБорисов можно ли на гитхабе сделать православный merge с fast forward или rebase, как если бы PR был локальной веткой?

Удаление и восстановление ветвей в запросе на вытягивание

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

Deleting a branch used for a pull request

You can delete a branch that is associated with a pull request if the pull request has been merged or closed and there are no other open pull requests referencing the branch. For information on closing branches that are not associated with pull requests, see «Creating and deleting branches within your repository.»

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click

Pull requests.

To see a list of closed pull requests, click Closed.

Restoring a deleted branch

You can restore the head branch of a closed pull request.

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click

Pull requests.

To see a list of closed pull requests, click Closed.

Further reading

• «Creating and deleting branches within your repository»
• «Managing the automatic deletion of branches»

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

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

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

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

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

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

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

• Со стороны рецензента переходим к тому же репозиторию 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.

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 .