Photo by Oleg Devyatka on Unsplash

How to keep on top of pull requests

… and how not to

Michael Winch
5 min readJul 12, 2023

--

When working in an active team, you can become bombarded with pull requests (PRs) to review and it can become impossible to keep on top of them. Fortunately, we have tons of tools at our disposal to do just that. Unfortunately, we have too many tools and now you have a new problem — how do I manage all these notifications?

Here are a few options…

Email

Set up by default, GitHub will send emails to your connected addresses whenever you’re requested as a reviewer on a PR.

If you use the same account for work and personal projects like I do, you’ll end up receiving emails about work to your personal address which is a pain.

But there’s a solution!

In your notification settings, you can set your default email (probably your personal one), and separate email addresses for each organisation. Just click on the Custom Routing button and add a new route.

Notification settings
Custom Routing settings

Review Requests

One of the first features I relied on, this is an easy way to see every request that’s waiting on you.

Once you review the PR it will drop off the list, which is great… until you don’t want it to. I often find that once I’ve reviewed a PR, I’ll want to stay in the loop about changes and feedback that other people have given. The feature doesn’t really allow for this use case, which is why I stopped using it.

Pull request review requests

Notifications

The first time I looked at GitHub Notifications I saw the 11,000 unread items in my inbox and immediately left, and I’m sure I’m not alone. Left with the default settings Notifications is unusable, but if you carefully curate them it can be a very powerful tool.

The first thing I did was unwatch all repos that I’m not involved in, which was in the hundreds as it added all repos in the organisation by default. If you want, you can also change your settings per repo to only notify you of @ mentions or participation.

Then, I purged all the old notifications by marking them as done.

Suddenly I had an environment where every event is something I care about and probably want to do something about.

This isn’t for the faint of heart though — you have to keep on top of notifications and mark them as done. If you’re like me and like to have 0 unread emails in your inbox you’ll have no problem, otherwise I may suggest you use one of the other options.

Slack Integration

Similarly to Notifications, there is a GitHub integration for Slack which notifies you whenever an event happens, except this will send you a message straight to your Slack app for each event.

Some people may love this but I find this endlessly distracting. Trying to concentrate on some complex business logic and having a ding go off every few minutes isn’t my idea of a good working environment.

It also takes a bit of setting up as you have to subscribe/unsubscribe to every repo with a Slack command.

/github subscribe totallymoney/AwesomeFeature
/github unsubscribe totallymoney/AwesomeFeature releases deployments

If that doesn’t bother you, and you’re happy to use a UI which amounts to a chat log to manage your subscriptions, then this can be a strong solution.

Other related tools

Whilst not directly notifying you of changes, there are other tools that can help you keep on top of PRs.

You can set up teams which allow you to mention or request a review from a group of people.

You can also make use of the codeowners file to auto-request reviews from any number of people.

DMs. If you’re waiting on a review from someone, you can always send them a message on your platform of choice to remind them to have a look. But please don’t (sometimes).

Now what?

Well, pick one. Or two. But whatever you do, don’t go overboard. When you’re inundated with information you end up either ignoring it or missing some. The best you can do is refine the information to the bits you care about, using the method that is convenient for you.

Personally, I solely rely on GitHub notifications, but you could get the same information using a combination of the Request Reviews feature and emails, or maybe the Slack integration will be enough for you.

What I will say is that each developer should be responsible for their own notifications.

Sending someone a DM to ask them to review a PR is a big distraction, because unlike the other methods this is a synchronous form of communication much like tapping them on the shoulder, and this will disrupt their train of thought which we all know too well.

We all have a lot to do and just because you haven’t heard back in a day doesn’t mean it’s not still on their radar. Maybe just mention it in stand up. Think about what a reasonable amount of time looks like for that person and if there have been any exceptional events that could cause a delay.

Of course, if you need someone to look at your critical fix you can go ahead and send that DM. But then if that’s the case you wouldn’t be reading this blog on how to keep on top of your PRs…

--

--