If you use GitHub, Bitbucket or VSTS regularly, you will be familiar with the term pull request. I believe GitLab uses the term merge request, but that it’s essentially the same thing (but don’t quote me on that).
What you do is create some changes, and request another contributor to merge those changes into (usually) the main branch. The idea is to have a place where you can see the changes and have meaningful discussions about it. The pull request can also be used to run a build with its tests for that specific set of changes.
The pull request is a very useful way of doing code review, and I recommend teams try it out. At first, you might fear that development pace will slow down, but if you take a correct approach, pull requests will actually increase your code quality, without slowing you down. In fact, by avoiding bugs and rewrites, you might argue it even increases your speed.
But there are caveats. Below are some tips on incorporating pull requests in your team’s workflow. I focus on GitHub, because that’s the most popular currently, but I would think other platforms have similar concepts.
Checks
The first thing I recommend, is to add checks to your pull requests. Checks allow your CI pipeline to kick in whenever a pull request is created. If the build fails because it doesn’t compile or any tests fail, you, the creator of the pull request, should fix that first. It makes little sense having another team member invest time in a pull request that doesn’t compile or has failing tests.
Be sure to read more on GitHub’s status checks. In VSTS, you can check out branch policies.
Assign the pull request
When all checks have passed, I find it useful to assign the pull request to a team member. There is a handy overview of assigned pull requests, and if you want, you can receive emails whenever someone assigns a pull request to you.
Depending on your team’s way of working, you might need to poke them in real life too 🙂
You could also opt to pull-model. Instead of “pushing” it towards a team member, have a “To Review” column in your task board and have any team member “pull” an item from there.
Review the code
Reviewing a pull request is in essence a small code review. And as with all code reviews, some guidelines apply.
Who?
Avoid always having the same person be the reviewer. This can create a bottleneck when that person gets too many pull requests to review. It also has a negative effect on the team dynamic, as that one reviewer might start making everyone code like he/she would, while other team members stop adding their valuable feedback. This situation leads to apathy and indifference.
Respect
Keep it respectful. You should assume that the other developer did his best, knowing what he knows and given the constraints he has. Don’t think you would never make any mistakes. Engage in a constructive discussion that works towards a solution.
Timeliness
Don’t let pull requests stall for too long. If you keep pull requests open for too long, it might hinder the business, it might keep other developers from continuing off of the pending changes, and it makes it increasingly harder for everyone to remember the context in which the pull request was created.
I’ve encountered situations where a pull request was only reviewed after a few weeks. When any remarks came, I had to take myself back to the days when I wrote the changes. This would have been easier if it had been minutes or hours, rather than weeks.
It also coincided with a subsequent pull request that was needed urgently, but built upon the changes of the first pull request. Needless to say, this is not a good situation, because then things need to be rushed.
Don’t be the one stalling your team. When a pull request is assigned to you, don’t leave it hanging for days on end. It shows you don’t value the other developer’s work and time. Start any discussion early, so you can close the pull request quickly.
Minor disclaimer: this is different in certain open-source/hobby projects, where developers work in their personal time, and might not always be available immediately.
Sync or async?
When having a discussion about the code, you can use the GitHub interface (async) or do it in-person (sync). Both have advantages and disadvantages.
Using GitHub allows you to talk on your time and it allows you to do so remotely, if necessary. It also provides a convenient log of the discussion for later. A drawback could be that context is lost, or certain words or phrases are misunderstood (due to missing intonation and facial expression).
In a well functioning team, using GitHub should work out fine. People will communicate respectfully and in a timely manner. And if the communication becomes difficult, just take some time to sit together and work things out.
Merging
When all is said and done, the time comes to merge. You can either allow the reviewer to do the merging, or just approve the pull request and let the author merge. Find out what works best for your team.
Obviously, another build must kick in, and maybe some extra steps are necessary (e.g. versioning, deploying, etc).
Conclusion
Using pull requests in your team’s work flow may seem a step back at first (I thought so too), but I’m confident any team can find a way to use it for the better. All team members can participate in the review and discussions, leading to a better exchange of knowledge. Any improvements can be identified before having it merged to the master branch, which means faster feedback, and less time lost changing it afterwards. But there are some points to keep in mind, like respect and timeliness. If you incorporate all that in your workflow, pull requests should help you produce better software at the same or even faster pace.