How do I merge pull requests on GitHub?

Merging makes Git great, but it helps to know how and what you should do to get the most out of your merges. On GitHub, there are multiple merging options to choose from, and not all of them are perfect for your project's needs. Keep reading to learn what pull requests are all about and how you can merge them more effectively.

What are pull requests?

GitHub pull requests are essential to the overarching development flow used on the platform. Pull requests make it possible for contributors to a given project to ask decision-makers to merge their contributions into it. Without pull requests, project contributors and leaders would be forced to engage in lengthy back-and-forth interactions to reach a consensus on what changes would be allowed.

Pull requests bake in all of the essential details to simplify this process, such as code reviews, which can be handled by authorized maintainers and/or via continuous integration automation to ensure code contributions meet the project's minimum requirements for security, style, and more.

What happens during a pull request?

Pull requests follow a simple trajectory from start to finish. The entire process can be summarized into four distinct steps:

1. The initial pull request is created.
2. Metadata is added to the request as needed. This includes details such as a summary of the proposed code changes, milestones, and @ mentions for individual team members, etc. Additional commits can also be added to your pull request as necessary.
3. The code changes laid out in the newly minted pull request are reviewed by project leaders and stakeholders. Alterations can be made or suggested at this stage before the request is accepted.
4. Once the pull request has passed inspection, it can be merged into the official repository.

Pull requests vs. merge requests

Depending on where your project is managed and what platform you’re using to handle pull requests, you may encounter the term "merge request" as well. However, the two are essentially identical in purpose, use, and effect. That's right: Pull requests and merge requests are the same thing. What GitHub calls a pull request, GitLab calls a merge request. Technically, both terms accurately reflect what happens when such requests are made—only the former refers to the beginning of the operation, while the latter refers to its end.

On the other hand, the act of merging a pull request is more specific and refers directly to the final stage of the pull request process, in which the merge itself is handled. The alternative to merging the pull request would be closing it—a handy feature to use when the contributions offered by a given pull request are not needed.

How to merge pull requests on GitHub

Repository managers and team leaders can merge multiple pull requests whenever they want to. However, pull requests are typically inspected with some care and caution before being merged into a project's core branch, as this cuts down on potential problems with code quality and consistency down the line. The merging process itself is relatively simple overall, but there are a few different ways to handle it. Here are the three most common scenarios:

Standard pull request merging

In this case, pull requests are usually merged: the "merge pull request" option is selected on GitHub for the pull request in question. With that out of the way, you can select a merging option to use for the operation. There are three main options available:

1. Moving all feature branch commits to the base branch. This is the default option available on GitHub and can be expected to run if no other option is selected. Although this option is relatively simple, it can be a bit of a nuisance to use in some projects, as it’s capable of generating an inordinate amount of clutter. If you’re not interested in stuffing your project's history with insignificant feature branch commits, then this is probably not the right option to use.
2. Squashing all commits and moving the resultant commit to the base branch. This option helps reduce the commit clutter issues the default merging operation causes. Before the actual merge is completed, commits on your feature branch are squashed into a single commit, which is then merged into your base branch. This makes it possible for your merge to be carried out with the "fast-forward" algorithm (the head pointer is simply moved forward to the new squashed commit). Although this approach provides clarity in a fast-moving project, it’s not ideal for projects involving long-running feature branches (those that will not be deleted after each merge with the base branch). Merge conflicts are more likely to occur when squashing is used on branches you plan to keep contributing to, as commits will be repeated (in a single commit) on the base branch while continuing to exist in the feature branch.
3. Rebasing all commits and merging the results. Rebasing makes it possible to effectively rewrite your feature branch's history, beginning from the common ancestor it shares with the base branch. Once finished, a fast-forward type merge can take place, yielding a linear project history that’s easier to read and less prone to merge conflicts in the future.

Merging pull requests into protected branches

Whenever a merge is attempted on a protected branch, it has to pass all the branch protection rules that have been set in order to proceed. These rules range from requiring full reviews of code contributions to making the feature branch's history linear.

Automatically merging a pull request

Automatically merging pull requests is another option developers can choose to simplify their workflows. Automatic merges can be triggered in a variety of ways, ensuring prospective merges meet all necessary requirements before they are incorporated into your master branch.

How Mergify can help 🥰

Mergify makes merging on GitHub much easier to manage—and automated to boot! With Mergify, you benefit from automatic merging, serial merge queuing, and much more. Sign up today to give Mergify a try.