What not to do while opening a Pull Request

Pull requests, otherwise known as merge requests, tell your team members about the changes you’re going to merge. They help others to keep track of the changes in the code base, serve as documentation, and can mitigate the possibility of bugs in production. Taking this into account - having well-written pull requests will get your code to production faster so here are tips on what to avoid to make them even better.

Don't forget about the description

While opening PR, you shouldn’t completely ignore the description. This part of PR should tell the reviewers what to expect from your change and what the goal is, simply put, what you did and why. That way, they can quickly pick it up and give you feedback as soon as possible. On the other hand, you should not abuse the description to explain every line of code.

The best descriptions are high-level overviews and contain all the information needed to review the code. In other words, if the reviewer has to leave the pull request to get more information then it’s not a good pull request. Try to imagine yourself in the reviewer’s shoes and ask yourself, what would they need to know?

Don't solve everything with only one PR

We know that it might be tempting to solve the whole ticket with only one pull request but please, don’t do that. Larger pull requests either take much longer to get approved or they are too rushed and not given proper attention. The more things you are changing at a time the more time it takes to understand and review every single part. Not to mention that large pull requests are really daunting to review.

It’s best practice to send small pull requests that change only one thing because it speeds up the process and your changes can be merged more quickly.

Don't send PR without testing/reading it first

All of us know the excitement of committing the last changes to our branch and we just cannot wait to send it to review. However, we shouldn’t forget about testing these last changes as we could have broken something else.

Once you’re sure that everything is working properly, make sure to read the diffs while opening the pull request and double-check that you haven’t deleted anything by mistake or committed something that you did not want to.

Don't forget about staying up to date with the MAIN branch

When developing a feature for some time, it is important to not forget about your co-workers and their work as it can simply lead to merge conflicts after your pull request is approved.

As you can guess this can really prolong the time for merging your change and can be prevented by merging the main branch on a regular basis.

Don't take offense

Surely you’ve already experienced that most of your pull requests are commented on and need some adjustments before getting the green tick by your team members. And even though it sometimes seems that all of the reviews started to pick on you, know that they only want you to become a better developer.

So don’t take the comments personally or as an attack on you but rather think of them as a necessary part of your developer journey.

Don't end with Pull Request and not care about the rest

Try to think about the pull request as one part of the whole development process. That means that after getting approval for your change, your work is not done and you should make sure that the code is pushed to production as soon as possible. This really depends on the deployment process of your company - most companies should have CI/CD pipelines where almost every member of the team can push to production.

Conclusion

Pull requests can feel like a chore, and that’s why it’s important to keep both parties interested. With small and well-described pull requests you’re definitely increasing your chances that someone will swiftly pick up the pull request and will be excited to review it quickly.

BONUS TIP - Make reviewer life as easy as possible

As we’re only humans, it’s natural that we sometimes overlook unnecessary else, unused variables/imports, or we just simply duplicate some part of the code. However, there is a simple way how to avoid it and therefore save a lot of time instead of sending pull requests back and forth on these repetitive and really easy-to-fix changes.

By using our tool Codeac, you get actionable feedback after each commit so you are able to keep the quality of the codebase at a high level and get comments and suggestions for fixes on parts that really matter, and consequently have your pull request approved as soon as possible.

Try Codeac.io for free and see how it can speed up your PR throughput.