When a user submits a pull request, their collaborator has a right to review it. After the review process, the collaborator can decide to accept or reject the pull request and, if accepted, will merge the new code with the requested branch.
But what’s the best way to review a pull request properly? Let’s find out.
Why Does a Request Need to Be Reviewed?
To start, an excellent question to ask may be, “why is this being reviewed, anyway?”. A review allows collaborators to discuss potential changes before enacting them. It also ensures that the code in question is up to the quality standards necessary for the main project. By reviewing sections before they are put into use, iteration and conversation can be leveraged to make sure the best possible product is being produced.
What Makes Reviewing Pull Requests Challenging?
While the concept of having a back and forth on the merits of the code may sound like a great innovation and will likely lead to stranger underlying code, programmers can find creating pull requests annoying. Some may not want to interact with other collaborators, defend their approach to the code, or know exactly how to articulate how the change is beneficial. In that sense, commenting on code can get a bit personal, and, when reviewing pull requests, as a collaborator, it’s a good idea, when leaving comments, to stick to commenting on the code itself – not the author.
What to Look Out for in a Git Pull Request
When evaluating a pull request, look out for:
- The intent of the changes (why are these changes being made?). If you are confused by the purpose of the changes, it’s a good idea to take a step back and read the task given to the collaborator and look at both the task and request side by side so that you have the full context of the pull request.
- The impact the changes will have on the project (can something break if this change is accepted?). It’s a good idea to run the code in your head and play out scenarios to see if you can find an area where the change may go wrong – or how it can affect other parts of the application.
- Readability (does a variable name accurately show what’s in it?). Within reason, try to optimize for readability, and if you can adjust it for clarity, do so. It will help your entire team down the line if everything is easily readable.
- Bad habits (are there style mistakes that can be corrected?). Use a code review as an opportunity to educate your collaborator in a positive way. If you see an error, point it out, and give a reason for the correction. You’ll be creating standardized work that’s easy for the entire team to understand if and when the code needs to be revisited by weeding out bad habits.
Should I Review the Pull Request with the Author?
While it may seem like common sense to review the pull request with the person writing it, consider reviewing it with someone else on the team. That way, you aren’t as likely to be biased by the author’s explanations. Getting a third party involved can also help standardize best practices, as more people will have to be aware of the best ways to communicate changes, and there’s less likelihood of falling back on shorthand that other team members may not understand.
Stay Away from Sizable Pull Requests
Pull Requests should be small and shouldn’t contain multiple changes. Make it a habit to separate out concerns as individual pull requests. This not only makes pull requests easier to review and understand, but it also keeps each change separate so that if something does go wrong, instead of having to fix 20 things, you can focus on the one.
Pull Requests Outside of Git
Did you know you don’t have to check pull requests from Git or GitHub? With Bitband, users can check pull requests right in Jira for easy review outside of Git. This is possible across multiple plugins, including GitHub, Git, GitLab, Bitbucket, Gitea, and Beanstalk.
Conclusion
By keeping pull requests small and contained, considering the impact of the changes, and reviewing with third parties, you’re going to make your code much stronger.
If you use Git and Jira to help your teams communicate and stay organized, make sure they are integrated together to make conversations even easier. Try our apps for GitHub, Git, GitLab, Bitbucket, Gitea, and Beanstalk – all of which allow for easy integration with Jira!
Want more Bitband insights? Check out:
