How to delete pull request

Reverting a pull request

In this article

You can revert a pull request after it’s been merged to the upstream branch.

About reverting a pull request

Reverting a pull request on GitHub creates a new pull request that contains one revert of the merge commit from the original merged pull request. To revert pull requests, you must have write permissions in the repository.

Reverting a pull request

Note: You may need to revert the individual commits in your pull request if either of the following is true.

For more information about using Git to manually revert individual commits, see Git revert in the Git documentation.

Under your repository name, click

Pull requests.

In the «Pull Requests» list, click the pull request you’d like to revert.

Near the bottom of the pull request, click Revert. If the Revert option isn’t displayed, you’ll need to ask the repository administrator for write permissions.

Merge the resulting pull request. For more information, see «Merging a pull request.»

Help us make these docs great!

All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.

Как отменить пулреквест на гитхабе?

Как можно отменить пул-реквест на github?

7 ответов

В основном вам нужно проделать следующие шаги:

Пример (кнопка в самом низу):

Таким образом, запрос на перенос закрывается (и игнорируется) без его объединения.

Но поскольку система запросов на вытягивание GitHub также включает раздел обсуждения, в котором вы могли бы высказать свое беспокойство получателю этих изменений, попросив его / ее игнорировать 29 из 30 ваших коммитов.

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

Если вы отправили пул-реквест в репозиторий, где у вас нет прав на его закрытие, вы можете удалить ветку, из которой был получен пул-реквест. Это отменит запрос на перенос.

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

Если вы открыли PR на gitHub, но он еще не объединен и вы хотите избавиться от него, а не просто закрыть, выполните эту простую команду:

У меня такая же проблема. Что я сделал

How to Easily Revert Git Pull Requests

Many of the organizations that use Git—and probably the vast majority of open-source projects as well—employ a workflow centered around the pull request. The pull request is the process by which a potential contributor asks the maintainer of a project to accept their branch and merge it into the project’s mainline. Accepting and merging a pull request should signal the end of the specific contribution, but if things don’t work as planned for some reason, you might need to revert a pull request in Git.

That’s what this post is about: explaining how to revert a merged pull request. Before we go there, we’ll talk about the pull request process itself, explain how it works, and give examples of situations in which you’d need to revert a PR.

With those basics out of the way, we’ll finally tackle the «how.» You’ll learn how to revert a pull request in GitHub, in GitLab, and also in «vanilla» Git, using the git revert command. Let’s get started.

Table of Contents

The Pull Request Process: What It Is and How It Works

As promised, let’s start by tackling some fundamentals. Specifically, we’ll open by defining a pull request.

What Is a Git Pull Request?

A pull request is a process by which a contributor to a Git repository offers some code and asks for the project’s maintainer to accept it and merge it. Pull requests are not a feature of the native Git software. Rather, they are a feature of source code hosting providers. First popularized by GitHub, nowadays they’re common in other platforms such as GitLab, BitBucket, and Azure DevOps.

(To make things slightly more confusing—because, why not?—Git does offer a command called request-pull. It predates hosting services such as GitHub and what it does is generate a list of changes in the format of a patch file which gets sent by email.)

How Does a Pull Request Work?

The way a pull request—or merge request, as they’re called in GitLab—works varies depending on the source code hosting service you’re using. I’ll describe what the workflow might look like for a company using a service such as GitLab or Azure DevOps.

It should be noted that in practice this process can take a surprisingly long time. In fact, on average code reviews sit idle for 70% of cycle time! That’s why PR merge time is one of the core metrics for companies like Slack.

Why Would You Want to Revert a Pull Request?

Here are some of the reasons why you might need to revert a pull request:

It’s vital to stress that reverting a pull request should be the exception rather than the norm. Having problems like the ones above is a sign your team has deeper issues that it needs to address. For instance, merges resulting in conflict are often caused by pull requests taking too long to be reviewed and merged. Pull request pickup time is an important engineering metric that you should work to improve. With LinearB, you can get a detailed breakdown of your development cycles so that you can determine if valuable time is being wasted by pull requests sitting idle.

How to Revert a Pull Request

With the «what» and «why» out of the way, let’s explore the how. We’ll start by explaining how to revert a pull request in GitHub.

Reverting a Pull Request in GitHub

GitHub offers the functionality of reverting pull requests. To illustrate this, I did the following:

On the repository’s page, I go to the pull requests tab and filter to see the closed PRs:

After clicking on the PR, I access the detailed pull request page where I can see the Revert button:

This button does an interesting thing. It offers me the chance to create a new pull request whose changes effectively undo the changes resulting from the merge:

I only have to click on the Create pull request button and I’ll be redirected to the page of the new pull request:

We can see that this pull request contains three commits. I’ll go over there to inspect them:

Interestingly, GitHub created three new commits that undo the three original commits that I added when accepting the pull request (I’ve used the «rebase» option when accepting the PR, which means I’ve preserved the original commits as they were in the new branch.)

Completing the reversion is a walk in the park: just complete the pull request and you’re done.

Reverting a Pull Request in GitLab

GitLab is a bit less resourceful than its competitor when it comes to reverting pull requests. GitHub offers the ability to revert pull requests regardless of the method you used while merging them. Whether you rebased or squashed, used a fast forward merge or a merge commit, GitHub will be able to revert the changes. However, GitLab only shows the Revert option for projects that use git merge (which produces a «merge commit») when accepting merge requests.

This time I did the same steps I did before to create a merge request with a few commits:

Then I created and accepted the merge request:

Notice the Revert button at the top. After clicking it, I’m prompted to configure a few options:

I’m satisfied with the default options, so I click the Revert button, which brings me to the new merge request page:

The rest is super simple: I finish creating the PR, then merge it, and the original pull request is no more.

Reverting a Pull Request Using Git

What if GitHub and/or GitLab didn’t offer the option to revert a PR? You could still use vanilla Git to revert a pull request. Let’s see how you can do that in two ways.

The Non-Destructive Way: The Git Revert Command

Under the hood, both GitHub and GitLab resort to the git revert functionality. So, there’s nothing stopping you from using the same command.

Here’s a step-by-step guide of how you’d go about it:

The Destructive Way: Git Reset

Git revert is a safe, non-destructive command. When you use it, you don’t rewrite past history. Instead, you create new commits whose changes are the opposite of the ones you’re trying to undo. The new commits and the old ones cancel out, and the changes no longer affect the repository.

However, you might have a legitimate reason to rewrite history on the default branch. If that’s the case, and you understand the risks and have the privileges to overwrite the default branch, you could simply do:

Then, you’d just have to force push the change:

I can’t stress this enough: only do the above if you’re really sure of what you’re doing. Rewriting public history is a bad practice and you can harm your coworkers. No one will be able to look at the history of the codebase and rely upon the commit messages to see how the codebase has changed over time. Doing a hard reset is a risky operation and you can lose commits—and a codebase’s true history—for good.

Standardize Your Pull Request Process

Generally speaking, reverting a pull request isn’t something you should do often. It is often necessitated by causes that could be avoided. LinearB’s goal-setting frameworks, metrics, and WorkerB automations can help your team successfully adopt a robust code review process that will enable you to consistently ship better code faster.

Want to improve your engineering processes at every level? Get started with LinearB today!

But it is nice to know that, if the need arises, reverting a pull request is quite easy to do. As you’ve seen, both GitHub and GitLab offer user-friendly ways to perform this operation, which, under the hood, rely on the git revert command.

Even if your favorite source code hosting service doesn’t offer an option to revert pull requests, you can always use the git revert command yourself. As a last possible resort, if you really know what you’re doing, you could also perform a hard reset to «get rid» of the offending commits.

Complete, abandon, or revert pull requests

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Visual Studio 2022 | Visual Studio 2019 | Visual Studio 2017 | Visual Studio 2015

Once all required reviewers approve your pull request (PR) and the PR meets all branch policy requirements, you can merge your changes into the target branch and complete the PR. Or if you decide not to proceed with the changes in the PR, you can abandon the PR.

To address reviewers’ changes, and respond to and resolve review comments, see Address comments.

Prerequisites

Repos must be enabled on your project. If the Repos hub and associated pages don’t display, see Turn an Azure DevOps service on or off to reenable Repos.

To complete your PR, you must be a member of the Contributors security group, or have the corresponding permissions, in the project the PR is in.

To contribute to a PR, you must be a member of the Readers security group or have the corresponding permissions.

To view or review PRs, you must have Basic or higher access to the Azure DevOps project.

If you aren’t a member of the project you want to contribute to, get added.

For public projects, users granted Stakeholder access have full access to Azure Repos.

Check merge changes

When you complete a PR, Git adds a new merge commit to the end of the main branch. This merge commit links the earlier histories of the main branch and the PR source branch. To see the preview merge commit and check for merge conflicts, select the More options menu at upper right on a PR Overview page, and then select View merge changes.

If you changed the target branch after creating the PR, select Restart merge to create a new preview merge commit and update the merge change diff view.

Review branch policies

Teams can set branch policies that require PRs in protected branches to meet specific criteria before the PRs can merge. You can see the branch policies in effect for your PR, whether they’re required for merge, and whether the PR is passing or failing.

The PR Overview tab summarizes branch policies that are passing or failing for the PR. The overview lists only failed policies, but you can see all the policy checks by selecting View checks.

In Visual Studio 2015, 2017, and 2019, you can access PRs from Visual Studio Team Explorer:

Select View > Team Explorer to open Team Explorer. You can also press Ctrl+\, Ctrl+M.

From Home, select Pull Requests to view lists of PRs opened by you or assigned to you.

To open a PR in the web portal and view the policies in effect, right-click the PR and select Open in browser.

To see all branch policies that are in effect for a PR, use az repos pr policy list with the required id parameter.

Parameters

Example

For example, to see the policies in effect on PR #28, run the following command:

Azure DevOps CLI commands aren’t supported for Azure DevOps Server on-premises.

Complete a pull request

After you resolve any merge conflicts, and the PR meets all branch policies and has all required approvals, you can complete the PR.

Select Complete at upper right to complete the PR. Or select the dropdown arrow next to the Complete button, and select one of the options.

In the Complete pull request pane, under Merge type, select one of the merge options.

Existing policies are enforced. For example, if your branch currently has a «squash merge only» policy, you have to change that policy if you want to use another merge type.

Select any of the following post-completion options. Some options aren’t available for some merge types.

Select Complete merge.

Select Complete at upper right to complete the PR. Or, select the dropdown arrow next to the Complete button, and select one of the following options:

On the Complete pull request screen, enter the message for the merge commit and update the PR description.

Select any of the following options:

Complete linked work items after merging to complete any linked work items.

Delete
after merging to delete the source branch from the PR.

Squash changes when merging to squash merge your PR.

Override branch policies and enable merge to force a branch to merge even if it doesn’t satisfy all branch policies. This option is only available if you have Exempt from policy enforcement permissions.

Existing policies are still enforced. For example, if your branch currently has a «squash merge only» policy in place, you have to edit that policy in order to use the other merge types.

Select Complete merge.

When you complete the merge, any linked work items automatically update to show the PR completion.

Select Complete in the upper right of the PR view to complete your PR after the reviewers approve of the changes.

In Complete pull request, enter the message for the merge commit and update the PR description.

Select any of the following post-completion options:

Select Complete merge.

Linked work items are also updated showing the PR completion.

In Visual Studio 2015, 2017, and 2019, you can access PRs from Visual Studio Team Explorer:

Select View > Team Explorer to open Team Explorer. You can also press Ctrl+\, Ctrl+M.

From Home, select Pull Requests to view lists of PRs opened by you or assigned to you.

To open a PR in the web portal, right-click the PR and select Open in browser.

To complete a PR, open the PR in the browser, and on the Overview page, select Complete or set other options.

For example, to complete PR #21, use:

Set completion options

PR completion options include:

To set completion options and complete an existing PR, use az repos pr update with the required id parameter.

Parameters

Example

The following example completes PR #21, deletes its source branch, resolves its linked work items, and adds a merge commit message:

Azure DevOps CLI commands aren’t supported for Azure DevOps Server on-premises.

Rebase during PR completion

There are a few situations when rebasing during PR completion isn’t possible:

In all these cases, you can still rebase your branch locally and then push upstream, or squash-merge your changes when you complete the PR.

Multiple merge base issue

In some cases, a PR has more than one true merge base, and this situation can cause security issues. If the files in the PR have different versions between the merge bases, a multiple merge base warning happens. For more information and remediation, see Multiple merge bases.

Resolve merge conflicts

File changes in your branch can conflict with changes in another branch. When it isn’t clear how to merge changes, Git shows the files that conflict on the PR’s Overview page. You must resolve any merge conflicts between the PR branch and the target branch before you can merge a PR or set the PR to autocomplete. For instructions on resolving merge conflicts, see Resolve merge conflicts.

Set a pull request to autocomplete

Select Set auto-complete from the Complete dropdown list to complete and merge the PR changes as soon as conditions satisfy all branch policies. When the PR is completed, you receive an email notification. If a conflict or error prevents PR completion, email notifies you of the issue.

The Set auto-complete option is available in Azure Repos and TFS 2017 and higher when you have branch policies. If you don’t see Set auto-complete, you don’t have any branch policies. For more information, see Branch policies.

By default, a PR that’s set to autocomplete waits only on required policies. In the Enable automatic completion panel, you can choose to wait on optional policies as well.

Starting with TFS 2018 Update 2, the PR Overview page displays the list of outstanding policy criteria the PR is waiting for. If you set a policy to be required in the Enable automatic completion panel, you can set it back to optional on the Overview page.

Select Cancel auto-complete to turn off autocomplete.

A PR set to autocomplete displays an Auto-complete badge on the Pull requests page.

In the Pull Requests view in Visual Studio Team Explorer, right-click the PR and select Open in browser to open a PR in the web portal. On the Overview page, select Set auto-complete.

Set autocomplete to complete a PR automatically when it passes all required approvals and branch policies. You can set autocomplete at PR creation, or update an existing PR.

Azure DevOps CLI commands aren’t supported for Azure DevOps Server on-premises.

Abandon or reactivate a pull request

To abandon your changes and your PR without merging, select Abandon from the dropdown list on the Complete button. You can still view the abandoned PR, and it stays linked to work items.

To reactivate an abandoned PR at any time, open the PR from the Abandoned tab in the Pull Request view, and select Reactivate at upper right.

In the Pull Requests view in Visual Studio Team Explorer, right-click the PR and select Open in browser to open a PR in the web portal. On the Overview page, select Abandon.

Azure DevOps CLI commands aren’t supported for Azure DevOps Server on-premises.

Revert a completed pull request

To undo the changes from a PR, follow these steps. For more information, see Undo changes.

Open the completed PR and select Revert. This action creates a new branch with changes that undo the PR in an existing target branch in your repo.

In the Revert pull request pane:

On the New pull request screen, select Create.

Merge the new PR to complete the revert.

The branch created during this revert has a single commit that reverts all the file changes from the original PR. The branch doesn’t contain a reverted commit for each of the commits in the original PR.

Как удалить коммиты из пул реквеста

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

Я нашел несколько похожих вопросов в StackOverflow, но не могу применить то, что там есть. Это мой первый пулреквест на GitHub, поэтому мне странно, как все это работает.

мой журнал git

Может кто-нибудь объяснить, что происходит и как решить эту проблему?

У вас есть несколько способов сделать это.

Вот самое простое решение вашей проблемы:

Команда revert создаст новую фиксацию с отменой исходной фиксации.

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

Вот простой способ удалить неправильную фиксацию вместо отмены изменений с помощью откатной фиксации.

git checkout my-pull-request-branch

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

Если вы хотите добавить этот коммит в текущую ветку, но не имеет смысла быть частью текущего PR, вы можете вместо этого сделать следующее:

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