7 Ways to Manage Pull Requests

Pull requests focus on the changes made to the codebase with information about what change was made to help reviewers and other developers understand and provide feedback. Their biggest drawbacks lie in their detailed nature and time consumption. 

Developers make every effort to improve the management of pull requests, along with their workflow. There is a constant battle with ways to improve time spent on them and making sure the accuracy behind merging codes stays the same. 

We’ll talk about the challenges in managing pull requests and the best way to overcome them.

Challenges in managing pull requests

1. If the code is hard to read or comprehend

Recognizing and understanding how the code functions are part of the job. But sometimes, code is written in a way that makes it difficult to comprehend. Code can be refactored to the extent that the original code used is no longer readable, making it harder for a team to get tasks done.

2. Lack of reviewers

It’s important to have more than one code reviewer or code owner. This reduces the likelihood of an error during the merging process which causes inefficiencies in the team's workflow. 

3. Little to no information on commits

Commits and commit messages help developers understand why the suggested changes were made to the existing code. When there isn’t enough information on the commits, the reviewer loses context for the code. 

4. Merge conflicts

Merge conflicts can happen in two ways:

• When two branches (developers) have made changes to the same lines of coding
• One branch is working on a file that another branch has deleted

When either one happens, Git highlights the conflicting code but doesn’t know which code to keep and which to discard. Identifying and working through a merge conflict takes up additional time from engineers.

5. The time it takes to pass tests, review and deploy

Before code is merged, a pull request needs to undergo a series of reviews and unit tests before being officially deployed, to ensure that its functionality is aligned with the repository and any user acceptance criteria.

At Tara, the team pulls the branch, does a “clean”, and builds on the code if necessary. This step can take up a lot of time and affects the productivity of many developer teams. 

While this might be a partial list, it’s enough to understand why developers are looking for frameworks to build a more efficient pull request management system. 

If you resonate with the above, here are a few pointers that you can use to move faster in development and deliver priorities on time.

Best practices in managing pull requests

1. Set a daily limit on pull requests

At Tara, we usually work with three pull requests daily. Pull requests can take between 2 to 3 hours to review. Given most developers work an 8 hour day - that would be about 2 to 3 pull requests a day.

2. Establish coding standards and guidelines

What languages or frameworks are the teams using? Are there any shortcuts that need to be used? How are the commit messages being written? 

All of these questions are important in establishing a coding standard. If one team member writes code that team members cannot read or recognize, this affects team velocity. 

At Tara, we have established coding standards to help our team ship faster, more often. Some of those coding standards include standardizing the structure and logic of the code so that it's easy to review and merge.

3. Implement a one-to-one task pull request

One-to-one task pull requests are assignments that are allotted to developers. Our team uses one task to one PR relation in most cases. We recommend setting a one-to-one pull request standard from the beginning for a better workflow as it helps to create manageable Pull requests and a consistent system of record. 

Additionally, this makes it easier for team members to read each other’s code. It also gives the team space to focus on details - ensuring that the team is reviewing pull requests effectively. 

4. Review, review, review

Read over the code multiple times to ensure minimal errors. It’s important to take your time to do due diligence before merging.

Our engineering team sets a team of 3 for code reviews: one person who wrote the code and two others to review the code. This minimizes the margin of error and encourages constructive critiquing.

5. Sync your pull requests with a project management tool

While Github is great with managing pull requests, it’s not built to manage your daily activities. For engineering teams, an agile-focused tool is ideal to manage the team’s workflow, tasks and track progress.

We integrate Tara with GitHub to sync tasks with issues. This allows us to see PR statuses, blockers and check-ins on Tara, in one single view. Engineering managers can understand team performance on a pull request and code commitment level, which can help in assigning tasks and planning future sprints. 

6. Improve speed of PR reviews and merging with CI Automations

At Tara, we use Chromatic; an automated tool that gathers UI feedback to help branches correct any possible merging conflicts before deploying the code.

It cuts down the time spent by engineers looking for inconsistencies within the code by generating a report on the errors and bugs found so that the team can address those sooner.

7. Avoiding merge conflicts

A great way to avoid merge conflicts is through communication. Our team uses Slack for internal communication and short-term updates. A brancher will personally message another brancher to make sure the PR looks accurate before sending it off to be merged. 

Choose what’s best for your team

We’ve provided a foundation for better PRs and guidance to improve the speed at which the engineering team delivers. Remember that the priority lies in implementing the best practices that work best for your team. 

Understand your team’s strengths, weaknesses and capacity before adapting any framework. Adopt a methodology and workflow that fits your team’s expertise and headcount. Aim to only apply processes that produce productive outcomes, sometimes smaller teams require more flexibility and larger teams require more standardization.