There are many questions and opinions when it comes to reviewing source code. Code review can be difficult to stick with because people become busy with other tasks or feel it is too time consuming to go through the changes that have been made. Often, code review becomes a neglected task.

It can be challenging to make code review an integral part of your team's workflow; pull requests make that easier.

Development without pull request

A pull request notifies other development team members of changes made in your local repository. Pull requests provide the following functions:

  • Notify team members when a review or merge of work is needed
  • Display changes made to source code in an easy-to-understand manner
  • Provide a platform for communicating about source code

Pull requests are not a Git function. They were created by GitHub to make it easier for developers to participate in open source development, and, as a result, enabled them to create higher-quality source code. Pull requests are available in most major Git hosting services, such as Backlog and Bitbucket.

Benefits of pull requests

Below are a list of pull requests in Backlog. You can easily see which ones are open or have not been completed. This makes it easy for team members to review pull requests.

Pull request list in Backlog, a Git hosting service with bug tracking
Pull request list in Backlog, a Git hosting service with bug tracking features.

The creator and reviewer of a pull request can have discussions right on the page using comments. These comments are recorded on the server, so they can be revisited at a later time.g

You can also commit and push changes to a specific branch. The pushed commit will automatically be reflected in the pull request.

This structured code review leads to higher quality source code and provides greater context for future discussions.

Pull request comments in Backlog.
Pull request comments in Backlog.

Pull request clearly display what changes have been made to source code. The pull request creator can also add notes about what their goal was for the source code and provide supplementary information. This info helps inform the reviewer.

Changes are highlighted in the source code.

Development process with pull requests

Here is a simple development workflow with pull requests your team can follow:

  1. [Developer] Clone or pull the source of the work target.
  2. [Developer] Create a branch for the work.
  3. [Developer] Perform development work such as adding and modifying functions.
  4. [Developer] Push after the task is completed.
  5. [Developer] Create a pull request.
  6. [Review / Merge Personnel] Check the changes from the notified pull request and review.
  7. [Review / Merge Personnel] Judge the work and send a feedback to the developer if necessary.
  8. [Review / Merge Personnel] Merge if there is no problem as a result of the review.
  9. [Review / Merge Personnel] Close if the pull request itself becomes unnecessary as a result of the review.

Repeat steps 3 through 7 as often as needed to improve the quality of the source code.

developer - review pr