How to revert a Git Pull Request?

Pull requests are made on Git to work with a team collaboratively. In most open source projects, the contributors request the review and acceptance of a branch, and then depending on the vitality of the code, it is either accepted into the code or not.

A pull request serves as a crucial mechanism for contributors who wish to offer code enhancements to a project. It is a process where the project's maintainer is asked to review and potentially merge the contributions into the mainline branch.

While pull requests are a staple of collaborative coding, it's important to note that they are not a native feature of Git itself. Instead, they are a key function provided by source code management (SCM) platforms. GitHub was instrumental in popularizing pull requests, and today, they are a common feature across platforms like GitLab, BitBucket, and Azure DevOps.

Quick note: Though Git does offer a command called request-pull, this predates hosting services such as GitHub. It generates a list of changes in the format of a patch file, which is then typically sent by email. This nod to Git's history highlights the evolution of collaborative coding practices.

However, what happens when it is not merged and needs to be reverted? This is why we’ll tell you how to revert a git pull request.

Why is a Git pull request needed?

You want to avoid being in a position of reverting the pull request as often as possible, but sometimes, you just have to do it. And a lot of situations are beyond your control. So here are some of the reasons:

• The pull request was accepted and merged by mistake. This ends up with the original code having a bunch of broken code. 

• The commits made to a branch consist of unintended changes.

• The commit adds issues to the code affecting the functionality of the codebase.

• A conflict occurs with a different change in the codebase, so you need to revert until a solution is found.

• A new feature change was intended to be experimental but caused issues to the stability of the codebase.

• The pull request was associated with a different branch, which can happen when there is a complex branch strategy 

How to revert a Git pull request?

There are multiple ways you can revert a git pull request; some are safer than others. Here are some of the methods:

Creating a pull request for the revert 

Reverting a pull request in GitHub is a straightforward process that allows you to undo changes from a previous merge. Whenever a revert is made, it creates one revert of the merge commit. If you have write permissions, go ahead with the following steps:

• Navigate to Pull Requests: In your repository, click on the Pull Requests tab to view all existing pull requests.

‍

• Select the Pull Request to Revert: Find and select the pull request you want to revert from the list.

• Click on the Revert Option: At the right bottom of the detailed pull request page, you'll see the Revert button. Clicking this will initiate the revert process.
  • If you don’t have write permission, request your administrator for it.

• Create a New Pull Request: The revert action creates a new pull request that effectively undoes the changes from the original merge. You'll be redirected to a page where you can review this new pull request.

• Review the Reverted Commits: This new pull request contains commits that undo the original changes. It's important to inspect these to ensure they accurately reverse the changes.

• Complete the Reversion: Once satisfied with the review, complete the pull request as you would with any other, finalizing the reversion process.

This thorough approach ensures that any unwanted changes from a previously merged pull request are efficiently reverted, maintaining the integrity of your project's codebase.

Reverse using the git revert command

The Git revert command helps you create an inverse to the introduced changes and adds a new commit with these changes. This method is non-destructive, meaning it preserves the history of the repository while effectively negating the changes made by the pull request.

Here are the steps:

• Open your terminal and navigate to the repository where you want to revert the pull request.
• Use to show the commit history and find the ID of the commit you want to revert.
• Input the commit ID and execute the command. This does not erase the original changes but instead creates new commits that cancel them out.
• Provide a detailed Git commit message to clarify the reason for performing the Git revert, ensuring transparency in the project history.

This step doesn’t remove the changes made but adds changes to negate the pull request. If the merge was done using methods like squash or merge commit, you can target the resulting merge commit directly. However, if rebase was used, you’ll need to reverse each individual commit.

Reverse using git reset

The previous method altered the new reality caused by the merged unneeded pull request, but Git reset is like going back in time to change what was done.

While this might have unintended consequences, it might still be a route you can take if needed, and here is how you can do it.

• Find the commit hash that you want to revert to using the .
• Use git reset with the flag and the commit hash to reset the branch to that commit—for example, .
• Force-push the changes to the remote branch using .

It's crucial to understand the risks associated with this operation. Rewriting history, especially on the default branch, can lead to significant issues. You may disrupt the historical integrity of the codebase, making it difficult for anyone, including your coworkers, to trace how the code has evolved over time. This can impact collaboration negatively, as the shared understanding of the project's development might be lost.

Moreover, performing a hard reset can lead to the permanent loss of commits. This means you might lose valuable work and insights into the development process—something that cannot be undone. Be sure to thoroughly consider these potential consequences before proceeding, as the operation is not without its drawbacks.

How Does the Pull Request Process Differ Across Various Platforms?

Understanding how pull requests (PRs) operate on different source code management platforms—such as GitHub, GitLab, Bitbucket, and Azure DevOps—can significantly impact a team's workflow and efficiency. Each platform offers a unique experience when it comes to handling pull requests, though they all aim to facilitate collaborative coding.

1. GitHub

• Branching and Creating a PR: GitHub users typically start by creating a separate branch off the main branch. Once code changes are complete, a pull request is initiated with a brief title and description.
• Review and Discussion: GitHub emphasizes collaboration. Team members can review, comment on, and even suggest changes directly in the interface.
• Merging: After approvals, team members can merge the changes into the main branch, with options to squash or rebase changes if necessary.

2. GitLab

• Merge Requests: In GitLab, the term "merge request" is preferred. The process begins similarly with local branching and committing.
• Enhanced Pipelines: GitLab is known for its strong integration with CI/CD, allowing extensive testing to occur automatically once a merge request is created.
• Approval Processes: GitLab's robust approval settings let teams require reviews from multiple team members before merging.

      >> How to Revert a Pull Request in GitLab

        Understanding the Limitations

       Reverting a pull request in GitLab requires understanding the platform's nuances. Unlike GitHub, which allows you to easily revert any pull request regardless of how        it was merged, GitLab has specific criteria. In GitLab, the Revert option is available primarily for projects using git merge to accept merge requests. This method        results in a "merge commit," which GitLab can revert.

        Step-by-Step Guide

1. Create and Accept a Merge Request:
   • Begin by executing the standard procedure to generate a merge request. Include the necessary commits for your changes.
   • Next, submit and approve the merge request, merging it into the target branch using the git merge strategy.
2. Locate the Original Merge Request:
   • Navigate to the original pull request you want to revert. GitLab makes this straightforward for projects using git merge.
3. Use the Revert Option:
   • At the top of the merge request page, you should see a Revert button. Click this button to initiate the revert process.
4. Configure the Revert Options:
   • After clicking Revert, a prompt will appear with optional settings. Adjust these settings if necessary. However, most users find the default options suffice.
5. Create a New Merge Request:
   • Once satisfied with the options, proceed by confirming the revert. This action creates a new merge request that serves to reverse the previous changes.
6. Finalize the Reversion:
   • Follow the normal workflow to finalize this new merge request. Once merged, it effectively negates the original changes, thoroughly reverting the initial pull request.

       By following these steps, you can efficiently manage pull requests in GitLab while recognizing the limitations and capabilities specific to its platform.

3. Bitbucket

• Pull Requests and Branching: Bitbucket encourages a workflow that begins with branching, akin to GitHub and GitLab.
• Integrated Code Review Tools: Bitbucket offers detailed code review tools, fostering in-depth discussions and feedback.
• Automated Merging: This platform allows for automatic merging after all reviews are approved, streamlining the process.

4. Azure DevOps

• Comprehensive Integration: Azure DevOps stands out with its seamless integration with other Azure services, offering a unified workflow for project management and development.
• Required Reviews and Policies: Teams can set policies to automatically enforce code reviews, ensuring that every pull request undergoes a structured review process.
• Advanced Merge Strategies: Azure DevOps supports various merge strategies, providing flexibility based on the project's needs.

The Impact of the Pull Request Process on Software Development Time

The pull request (PR) process significantly influences the timeline of software development, often contributing to unexpected delays. One of the primary reasons for these delays is the idle time during code reviews. On average, code reviews can remain unaddressed for a substantial portion of the development cycle, which elongates the overall process.

This phase is commonly the most time-consuming aspect of development. Companies prioritize metrics like PR merge time because unresolved code reviews can lead to merging conflicts. When a PR is not reviewed promptly, it heightens the risk of conflicts that require additional time to resolve.

Improving the pull request pickup time can markedly enhance efficiency. Early attention to PRs reduces waiting periods, streamlining the process. Moreover, PR size plays a crucial role. Smaller PRs are typically easier and faster to review, which results in quicker merges and fewer issues.

In summary, by optimizing these PR-related metrics, teams can significantly reduce cycle times and improve overall productivity in software development.

Key Differences

While the core workflow of branching, making changes, and merging remains consistent, differences lie in integration capabilities, user interface, and review processes:

• Integration with Other Tools: Platforms like GitLab and Azure DevOps shine with their CI/CD capabilities, directly impacting the PR workflow.
• User Interface: GitHub is renowned for its user-friendly interface, whereas Azure DevOps provides a more integrated environment for larger organizational needs.
• Automation and Review Policies: Bitbucket and Azure DevOps offer automated processes to streamline approvals, enhancing productivity and reducing manual oversight.

In conclusion, while the fundamental concept of pull requests remains consistent, the nuances across platforms can greatly affect how teams collaborate and manage code. Understanding these differences can help organizations choose the best tool for their development needs.

Undo your pull requests but be smart about it

Pull requests are an integral part of working collaboratively, and merging them by mistake or without enough review can cause many issues to the codebase. Then reverting this process can have other consequences you want to avoid. Therefore, have an internal process to merge pull requests. Ensure everybody is on board with the code reviews needed for the process and a checklist to denote when a merge is acceptable.

Enhance Your Code Review Process

To further avoid the need for reverting pull requests, consider implementing a more structured approach:

• Use Tags and Context: Assign tags to your pull requests and provide context for the changes. This helps reviewers quickly understand the purpose and potential impact of the PR, streamlining the review process.
• Flag Risks: Identify and flag risks such as security vulnerabilities or the use of deprecated components early in the review. This proactive approach minimizes the likelihood of issues slipping through.

Address Core Issues

Reverting pull requests should be an exception, not the norm. If it becomes common, it may indicate deeper problems within the team. Addressing these core issues can lead to a more stable development cycle.

Optimize with Metrics

Improve your engineering metrics, such as the time it takes for a pull request to be picked up and reviewed. Long review times can lead to conflicts and delays, so work on reducing these durations.

• Focus on PR Size: Smaller pull requests generally get reviewed and merged faster, reducing the chance of conflicts and the need for reversion.

By adopting these practices, you can significantly enhance your code review process and minimize the need to undo pull requests, fostering a more efficient and reliable workflow.

‍