⇦ Back to: Review Pull Request | ⇧ Overview | ⇨ Next: Clean up

Merge a Pull Request, Split It or Close It

If Approved, Then Merge

Once you’ve been given feedback and it’s agreed that your PR is good to be merged into the main branch, it can be merged.

You or someone with the right to write to the repository can click the “Merge pull request” button in the GitHub Pull Request.

https://user-images.githubusercontent.com/2803227/194442629-4a867bee-91b5-4cb6-af9d-8f0caa4e51cb.png

It is also possible to carry out merges using the GitHub Desktop application, or the command line, but these may not work if the base branch is protected (see next section). We recommend using the web interface.

<aside> 🍎

It’s good merging etiquette to have the person who authored the PR merge it, if possible. Among other things, this makes it clear to author and repository owner alike, that the author has agency and is responsible for the work they’ve done.

This sometimes isn’t possible, for instance if the person has made the pull-request from a fork. In this case, ensure that the PR really is finished by checking with the author, before you merge it.

As a repository owner, you can enforce that a PR is only merged once it is approved by using branch protection rules.

</aside>

If Not Approved, Then Close

If the people working on the project think that a PR shouldn’t become part of the main branch for whatever reason, then you can close the PR without merging.

Add a comment, then click “Close with comment”. The PR stays in the list of closed PRs, and you can always revisit the conversation and the code associated with it.

https://user-images.githubusercontent.com/2803227/194443371-93dca0d8-bbe5-4fe2-b282-e66b99889d3f.png

If PR Needs Splitting, then Split It (Before Closing It)

Some PRs need splitting into several smaller PRs before they can be properly reviewed and merged.

If the commits were small enough, this is often extremely quick to achieve using the “cherry-pick” function of Git. In this mode, each commit is treated as a “delta” – the small change it applied to the code from before.

We recommend using the GitHub Desktop GUI for this, as selecting commits from the log can be more time consuming.

<aside> 🍎 It’s good etiquette to use cherry-picking like this to restructure work which someone else has done. It means that the original author will still be credited as the author of the commit, even if someone else actually presses “commit.”

https://user-images.githubusercontent.com/2803227/194585039-c9e06669-a96d-4813-ac06-1eb6e3a33fdb.png

For instructions on how to add co-authors on the command line, see the GitHub Docs on Pull requests

</aside>