top of page

How to create the perfect Pull Request?

Updated: Dec 9, 2022

Writing excellent code is as important as helping other people to review it

In software development, the output of a development team, i.e. the rate at which the team is pushing out features, depends on mainly 2 factors - the programming speed of the developers, and the speed at which code reviews happen.

Even if your team comprises of excellent developers, it does not guarantee that the output will be fast-paced. The bottleneck is usually the code review process on the Pull Requests.

Isn't your Pull Request backlogs piling up with so many iterations of comments and rectifications? What is the oldest Pull Request opened in your team's backlog?

I have observed, there are 3 types of Pull Requests -

  1. Minor Bug fixes, which don't receive comments and get merged very quickly.

  2. Modifications to an existing feature that receive 1 or 2 comments and also get merged quickly

  3. A big pull request which receives many comments and has many iterations of review changes and comments. - This is the culprit for slowing down your team's pace.

In this blog, I have mentioned 8 ways in which you can make your pull requests easier to be reviewed.

1. Make small Pull Requests (PR)

Creating small Pull Requests come with a lot of benefits - they are easier to review, code review is thorough and they will get merged quickly. Bug fixes and debugging are also easier if the PRs are small (as you would know which PR caused which bug ).

How important this point is can be understood from the fact that Google's development team has created a separate document on Small PRs.

So how do I create small Pull Requests for big changes?

It's simple actually.

- Split big changes into small parts and incrementally create PRs.

- When creating changes for a big feature, you can create small PRs and set the target to another base branch and not to `develop` or `master`.

2. Naming the branch and the Pull Request (PR)

I generally name the branch on "what the code is doing" and I name the PR on "what problem the change is solving". You should follow the naming convention your organization uses. Make sure that the title of your PR conveys the context of what to expect in the changes.

For example, if the feature requirement is to add demographics to the profile information,

I would name my branch as "adding-age-education-location-information-in-users-table"

My Pull Request title would be - "Added Demographics Information mentioned in [PL-1001]"