New Research Report - Exploring the 2024 State of Software Quality

Group 370

SAST, DAST, IAST, and RASP: Key Differences and How to Choose

Group 370

Spotlight Whitepaper by IDC on Importance of Automated Code Review Technologies

Group 370

Small Pull Requests: 6 reasons why they are the best choice

In this article:
Subscribe to our blog:

We know it’s easier to create large Pull Requests, and it might be tempting to do so. After all, writing smaller PR takes practice and even demands you to plan before coding.

But, in reality, writing larger PRs slows you and your team down, making your processes less efficient. So let’s take a closer look at why small Pull Requests are almost always the better choice.

You probably have been assigned to review a PR and had no idea where to start. On the other hand, you might have created large PRs, and another reviewer had a tough job. If the PRs were smaller, you could avoid all those issues. Let’s see six benefits of having small PRs.

Small PRs get faster code reviews

Engineers usually postpone code reviews when they see a big PR, and sometimes they forget about it completely! Even when someone starts reviewing a large PR quickly, it can take a long time to read through the entire Pull Request. 

The longer it takes to review a PR, the more likely the reviewer won’t do it in one go. With large PRs, reviewers often lose focus and get distracted with other tasks. On the other hand, small Pull Requests are reviewed faster, with few to no interruptions.

Small PRs get better code reviews

Reviewing large PRs is very consuming, mainly if the Pull Requests include multiple changes that make the reviewer constantly shift context. The result is that, at some point, the reviewer starts to skim code, leaves fewer comments, and ends up with a superficial review.

With smaller PRs, the reviewer can read all the code carefully and leave better and more valuable feedback.

Read our article on Pull request best practices.

Small PRs improve code quality

Reviewing work that is not ours can be difficult. It’s generally harder to spot problems and suggest improvements. Smaller PRs make it easier to understand the change in the code, allowing for better feedback and suggestions.

Plus, small PRs allow you to speed up the feedback cycle. You and your team will properly discuss the problem and the chosen solution earlier, allowing for better design decisions. As a result, you’ll have higher-quality code.

 Small PRs help protect your workflow

Small PRs allow you to have a better workflow. Getting back the review if something urgent interrupts your work is faster and less painful. Smaller tasks require you to keep less context in your mind, which makes it easier to get into a flow state.

Small PRs help you build features faster

Small PRs help you stay motivated and keep your momentum going. You’ll work faster by splitting large work into smaller tasks, and you will feel accomplished every time you merge a PR. In addition, you are less likely to get stuck because you know precisely what you are doing and what you will do next.

Small PRs improve collaboration

When you split work into smaller PRs, you’ll notice that it becomes easier to work on features together. Instead of a single engineer going through a feature independently for some time, you can have different engineers do the same thing much faster. Collaboration also has other advantages, like learning with each other and higher quality solutions.

How can you make small PRs

  1. Learn how to split your work. You first need to understand how to split your work into smaller segments. This comes with practice.
  2. Plan your tasks. Before you start coding, take a moment to list all the separate steps required to complete the job.
  3. Detach refactoring from feature work. If you need to refactor some part of the code when adding a new feature, create two pull requests: one for the refactoring part and another for the new work.
  4. Think about the reviewer. Give the reviewer all the necessary information in a short description. This allows the reviewer to have an immediate context about the PR.
  5. Prioritize code reviews in your team. Create a working agreement with your team where everyone agrees to do code reviews. This way, people will truly understand the benefits of smaller PRs when reviewing code.
  6. Conclusion

Having smaller Pull Requests improve the code review process and code quality. They help protect your workflow and let you move faster. Plus, smaller PRs facilitate feedback, improve collaboration, and reduce the risk of getting stuck.

We know that building small and focused PRs is a skill that requires practice. However, you’ll never get better if you don’t get started. So get to it and start with the next task you will work on.

Codacy Quality allows you to speed up code reviews, check your code quality, and track your technical debt. Start a free 14-day trial today!




Pull Request Best Practices
Developers are often so focused on writing code that they take other parts of the development process for granted; parts that, if upgraded, could...
Top mistakes your dev team makes when performing code reviews
Code reviews are an essential part of any software development process and are crucial for improving code quality. However, despite their importance,...
Why automated code reviews should be part of your workflow
Code reviews are one of the most important aspects of today’s software development workflow. With code reviews, your team can find issues early on,...

Automate code
reviews on your commits and pull request

Group 13