Creating a pull request
Last modified on Wed 12 May 2021

If the reviews hurt they're probably right on some level. - Sean Lennon

In the Infinum JavaScript team we love code reviews. We love getting them and giving them. This document aims to show how a good pull request should look like (no matter what SCM solution or tool). The main idea is to give your reviewer as much context as possible to allow them to focus on the feature or fix you have delivered.

Creating a pull request

Your pull request should have all of the below:

The following are extra but highly recommended:

Example

Pull request example

Implementing feedback

Once you fix up a comment leave a response that you've fixed that specific comment. This will help you reviewer do another pass on the feature when you hand it over for a re-review.

Going the extra mile would be to link the commit that fixes the comment.

If the pull request becomes stale in the mean time (diverges a lot form the base branch) consider merging the base branch back in so you get the review on possible merge conflicts as well.

When and who merges the pull request?

When the code review is completed with an appropriate number of approvers having signed off the feature the code can be merged.

You, as the developer, know best when and how this code should be merged. You press the green merge button!