The Correct Pull Request Settings

Pull Requests are how you get code from one branch into another - safely. This usually involves a combination of human reviewers and robotic automation.

We have a more detailed overview of PRs in our Ultimate Guide to Pull Requests - check it out if you aren't familiar.

In this post we'll cover the ideal set of settings to configure on your code repository to make Pull Requests as safe, efficient, automated, and pain free as possible.

Buckle up!

Most of the time (at least in GitHub.com) you'll find the settings for pull requests under the "Code and automation" section for branches named "Branch protection rules".

It looks like this:

github.com branch protection rules for pull requests

Add a rule for your main branch (named "main" most of the time), then gaze upon the abundance of configuration choice. Branch "protection" rules simply means the requirements you want developers to follow in order to merge code into that branch.

By targeting our main branch, we're setting rules for anyone trying to merge a feature branch into the main branch via PRs.

Which boxes should you tick? Let's dive in!

github.com require a pull request before merging

This is the single most required box to tick overall. It's how you enforce PRs as the mandatory way to put code into main in the first place.

If you don't tick this box, then instead of using Pull Requests, any developer can directly merge code into main. Since you learned that merging to the main branch triggers deployments,

Enable it and let's keep moving.

github.com require approvals

The "require approvals" setting makes PRs actually "do" something. Without it, anybody can file a PR then immediate merge it into main without any reviewers looking at it. Pointless, no?

Tick this box and set the number of required approvals to 1. It's not very often you need more than that, and odds are if you're practicing modern software development, your team size isn't big enough to warrant needing 2+ reviews to merge.

Tick tick this box to ensure all PRs get at least 1 approval and the reviewers feedback is addressed before merging.

github.com setting to dismiss stale pull request approvals when new commits are pushed

This handy little setting makes sure any new code that gets pushed into the PR branch clears out any existing approvals it's gotten thus far.

If the PR author tries to sneak something into a pull request after it's already bee approved, this'll stop em in their tracks.

The robots will re-run their checks and humans will have to get involved again (though still minimally).

Stay tuned, we'll add more settings soon!